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Abstract 


The  FX  programming  language  is  designed  to  support  the  parallel  imple¬ 
mentation  of  applications  that  perform  both  symbolic  and  scientific  com¬ 
putations.  Unlike  previous  languages,  FX  uses  an  effect  system  to  discover 
expression  scheduling  constraints.  The  effect  system  is  part  of  a  kinded  type 
system  with  three  base  kinds:  types,  which  describe  the  value  of  an  expres¬ 
sion;  effects,  which  describe  the  side-effects  that  an  expression  may  have; 
and  regions,  which  describe  the  areas  of  the  store  in  which  side-effects  may 
occur.  Types,  effects,  and  regions  are  collectively  called  descriptions. 

FX  expressions  can  be  abstracted  over  any  kind  of  description.  This 
permits  type,  effect,  and  region  polymorphism.  Unobservable  side-effects 
are  masked  by  the  effect  system;  an  effect  soundness  property  guarantees 
that  the  effects  computed  statically  by  the  effect  system  are  a  conservative 
approximation  of  the  actual  side-effects  that  a  given  expression  may  have. 

Effect  polymorphism  and  effect  masking  make  the  FX  effect  system  sub¬ 
stantially  more  powerful  than  previous  approaches  to  side-effect  analysis. 
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The  FX  programming  language  is  designed  to  support  the  parallel  imple¬ 
mentation  of  applications  that  perform  both  symbolic  and  scientific  compu¬ 
tations.  Unlike  previous  languages,  FX  supports  both  functional  and  im¬ 
perative  parallel  programming  by  a  static  checking  system  based  upon  the 
notion  of  effects.  Just  as  a  type  describes  what  an  expression  computes,  an 
effect  describe  how  an  expression  computes.  An  effect  is  a  static  descrip¬ 
tion  of  the  observable  side-effects  that  an  expression  may  have  when  it  is 
evaluated. 

When  a  programmer  uses  FX,  opportunities  for  parallel  evaluation  are 
automatically  identified  by  the  FX  effect  system.  The  effect  system  assigns 
an  effect  to  each  expression  in  a  program.  Since  the  effects  of  every  FX 
expression  are  statically  known,  effect  information  can  be  used  to  schedule 
a  program  for  parallel  evaluation  while  retaining  sequential  semantics.  If 
two  expressions  do  not  have  interfering  effects,  then  a  compiler  can  schedule 
them  to  run  in  parallel  subject  to  dataflow  constraints. 

The  effect  classifications  used  by  FX  include  read  effects,  write  effects, 
and  alloc  (for  allocate)  effects.  Each  effect  is  subscripted  by  the  region 
of  the  store  to  which  it  applies.  Compound  effects  are  built  from  unions 
of  simple  effects,  and  thus  effects  form  a  lattice.  The  bottom  of  the  effect 
lattice  is  the  effect  pure,  which  is  used  to  describe  an  expression  that  has 
no  effect  at  all. 

The  FX  effect  system  uses  effect  masking  to  erase  unobservable  side- 
effects  from  the  effect  of  an  expression.  Effect  masking  allows  expressions 
that  have  local  side-effects  to  be  scheduled  to  run  in  parallel  with  one  an¬ 
other.  In  addition,  the  same  static  analysis  that  is  used  for  effect  masking 
permits  local  storage  to  be  stack  allocated,  thus  saving  the  overhead  of  dy¬ 
namic  garbage  collection. 

The  FX  static  checking  framework  is  based  on  a  hierarchical  kinded  type 
system  which  includes  kinds,  universal  polymorphism,  higher  order  types, 
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and  recursive  types.  The  static  checking  system  is  based  upon  three  kinds  of 
descriptions :  types,  which  describe  the  values  expressions  compute;  effects, 
which  describe  the  side-effects  of  expressions;  and  regions,  which  describe 
where  effects  occur.  An  expression  may  be  polymorphic  in  any  of  the  three 
kinds.  Thus  the  type  of  a  subroutine  may  depend  on  the  effect  parameters 
passed  to  it.  Effect  and  region  polymorphism  permit  the  effect  system  to 
provide  tight  effect  bounds  on  higher-order  functionals  in  a  natural  and 
simple  manner. 

We  have  found  that  an  effect  system  is  useful  to  programmers,  compiler 
writers,  and  language  designers  in  the  following  respects: 

•  An  effect  system  lets  the  programmer  specify  the  side-effect  properties 
of  program  modules  in  a  way  that  is  machine-verifiable.  The  resulting 
effect  specifications  are  a  natural  extension  of  the  type  specifications 
found  in  conventional  programming  languages.  We  believe  that  the 
use  of  effect  specifications  has  the  potential  to  improve  the  design  and 
maintenance  of  imperative  programs. 

•  An  effect  system  lets  the  compiler  identify  optimization  opportunities 
which  are  hard  to  detect  in  a  conventional  higher-order  imperative  pro¬ 
gramming  language.  We  have  focused  our  research  on  three  classes  of 
optimizations:  code  motion  (including  eager,  lazy,  and  parallel  eval¬ 
uation);  common  subexpression  elimination  (including  memoization); 
and  dead  code  elimination.  We  believe  that  the  ability  to  perform 
these  optimizations  effectively  in  the  presence  of  side-effects  represents 
a  step  towards  integrating  functional  and  imperative  programming  for 
the  purpose  of  massively  parallel  programming. 

•  An  effect  system  lets  the  language  designer  express  and  enforce  side- 
effect  constraints  in  the  language  definition.  In  FX,  for  example,  the 
body  of  a  polymorphic  expression  must  not  have  any  side-effects.  This 
restriction  not  only  simplifies  the  type  system  by  making  effect  specifi¬ 
cations  on  polymorphic  types  unnecessary,  but  also  makes  this  the  first 
language  known  to  us  that  permits  an  efficient  implementation  of  fully 
orthogonal  polymorphism,  in  which  any  expression  can  be  abstracted 
over  any  type  and  all  polymorphic  values  are  first-class,  in  the  presence 
of  side-effects. 
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Organization  of  the  FX  Reference  Manual 

The  FX  manual  is  organized  into  eight  major  parts: 

•  An  overview  of  FX  conventions.  These  conventions  include  the  meta¬ 
notation  used  throughout  the  manual,  how  dynamic  and  static  errors 
are  documented,  and  the  reserved  keywords  of  FX. 

•  The  FX  Primer,  a  short  introduction  to  the  use  of  FX  with  examples 
(Chapter  1). 

•  The  FX  Kernel,  which  includes  essential  FX  constructs  and  the  FX 
type  and  effect  system  (Chapter  2).  The  Kernel  forms  the  core  of  the 
language  from  the  point  of  view  of  both  the  FX  application  program¬ 
mer  and  the  FX  language  implementor. 

•  Standard  FX  types  and  operations  on  refis,  booleans,  integers,  floats, 
vectors,  lists,  oneofs,  records,  and  so  forth  (Chapter  3). 

•  FX  Syntactic  Sugar  for  frequently  used  Kernel  constructs  (Chapter  4). 
Sugar  forms  (such  as  let)  do  not  add  semantic  power  to  the  language 
because  they  can  be  described  directly  in  terms  of  more  primitive  Ker¬ 
nel  constructs. 

•  The  FX  Environment  for  programming  (Chapter  5).  The  environment 
includes  I/O  facilities,  top-level  definitions,  and  facilities  for  developing 
large  FX  programs. 

•  The  BNF  syntax  of  FX  (Appendix  A).  The  syntax  describes  all  of  the 
special  forms  in  value,  description,  and  kind  expressions. 

•  The  semantics  for  the  FX  Kernel  (Appendix  B) .  The  semantics  is  used 
to  prove  the  soundness  of  the  parallel  optimizations  which  are  permit¬ 
ted  by  the  type  and  effect  system. 

This  report  corresponds  to  FX-87.  An  FX-87  interpreter  written 
in  Scheme  can  be  obtained  by  sending  an  electronic  mail  request  to 
gif  f  ordfixx .  lcs .  mit .  edu.  Subsequent  versions  of  FX  will  include  such  ex¬ 
tensions  as  separate  compilation,  exception  handling,  type  inference,  and 
explicit  concurrency. 
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The  FX-87  programming  language  was  developed  by  the  Programming 
Systems  Research  Group  at  MIT.  In  addition  to  the  authors,  Mike  Blair, 
Mark  Day,  Jonathan  Rees  and  James  O’Toole  made  contributions  to  the 
design  of  FX-87.  James  O’Toole  designed  and  documented  the  facilities  for 
implicit  projection.  Kendra  Tanacea  provided  helpful  comments  on  drafts  of 
this  report.  The  design  of  FX  was  strongly  influenced  by  Scheme,  especially 
in  the  choice  of  standard  types  and  operations. 

Your  comments  on  this  report  are  welcome. 
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This  chapter  presents  the  conventions  that  are  used  throughout  this  manual 
and  introduces  FX  syntactic  notation,  how  dynamic  and  static  errors  are 
documented,  FX  syntactic  classes,  and  FX  reserved  identifiers. 

Syntactic  Notation 

This  manual  adheres  to  the  following  conventions: 

FX  program  text  is  written  in  teletype  font.  Program  text  is  com¬ 
prised  of  identifiers,  literals,  and  delimiters. 

Meta-expressions,  which  are  names  for  syntactic  classes  of  expressions, 
are  written  in  italic  font.  A  programmer  may  replace  any  meta-expression 
by  a  compatible  FX  expression.  Meta-expressions  are  distinguished  by  their 
suffix.  For  example,  meta-variables  end  with  var  and  meta-expressions  end 
with  exp. 

In  the  following  example  specification,  if  is  a  reserved  identifier  and  the 
exp,  denote  any  valid  FX  expression: 

Example: 

(if  exp0  expi  exp2) 

Certain  FX  language  constructs  are  specified  to  take  a  variable  number 
of  parameters,  [exp]  denotes  an  optional  expression.  A  possibly  empty 
sequence  of  n  expressions  is  noted  expt  . .  .expn.  If  the  name  of  the  upper 
bound  on  subscripts  is  not  used,  we  write  the  shorter:  expl  ....  If  there  is  at 
least  one  expression  in  the  sequence  (i.e.,  n  >  1),  we  use  expt  exp2  . . .  expn. 
We  usually  denote  by  expi  (or  any  other  subscripted  exp)  any  expression 
which  belongs  to  any  of  these  sequences. 

When  a  given  FX  construct  cannot  be  kinded  (for  description  expres¬ 
sions)  or  typed  (for  an  ordinary  expression)  using  the  standard  FX  notations, 
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it  is  described  in  a  special  format  (double-barred  page)  in  which  explana¬ 
tions  are  given  on  its  syntax,  kind,  type,  effect  and/or  semantics.  One  or 
more  examples  of  its  usage  are  provided. 


Static  and  Dynamic  Errors 


Static  errors  are  detected  by  FX  when  a  program  is  type  and  effect  checked. 
All  syntax,  type,  and  effect  errors  are  detected  statically  and  reported.  The 
sentence  “x  must  be  y”  indicates  that  “it  is  a  static  error  if  x  is  not  y” . 

Dynamic  errors  may  be  detected  by  FX  when  a  program  is  run.  The 
phrase  “a  dynamic  error  is  signalled”  indicates  that  FX  implementations 
must  report  the  corresponding  dynamic  error  and  terminate  the  execution 
of  the  program.  The  phrase  “it  is  a  dynamic  error”  indicates  that  FX  im¬ 
plementations  do  not  have  to  detect  or  report  the  corresponding  dynamic 
error.  The  meaning  of  a  program  that  contains  an  unreported  dynamic  error 
is  undefined. 
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Here  we  describe  the  basic  lexical  entities  used  in  the  FX  programming 
language: 

•  A  digit  is  one  of  0  ...  9. 

•  A  letter  is  one  of  a  ...  z  or  A  ...  Z. 


•  The  set  of  extended  alphabetic  characters  must  include:  *,  /,  <,  *,  >, 
1 • »  t,  %,  kr,  , 


•  White  space  is  a  blank  space,  a  newline  character,  a  tab  character,  or 
a  newpage  character. 


•  A  character  is  a  digit,  a  letter,  an  extended  alphabetic  character,  +,  -, 
a  white  space  or  backspace  character. 


•  A  delimiter  is  a  white  space,  a  left  parenthesis  or  a  right  parenthesis. 

•  A  token  is  a  sequence  of  characters  that  is  separated  by  delimiters. 


•  A  literal  is  either  a  number,  or  a  token  that  begins  with  ’  or  #,  or  a 
sequence  of  characters  enclosed  in  double  quotes  ",  or  an  empty  set  of 
parenthesis  (). 
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•  A  number  is  a  token  made  of  a  non  empty  sequence  of  digits,  possibly 
including  base  information,  a  decimal  point,  and  a  sign,  (see  Chapter 
3). 


•  An  identifier  is  a  token  beginning  with  a  letter  or  extended  alphabetic 
character  and  made  of  a  non-empty  sequence  of  letters,  digits,  extended 
alphabetic  characters,  and  the  characters  +  and  Note  that  +  and  - 
by  themselves  are  also  identifiers. 

FX  reserves  the  following  identifiers.  Reserved  identifiers  must  not  be 
bound,  redefined,  or  used  as  tags  for  records  and  oneofs. 


alloc 

do 

one  of 

read 

type 

and 

effect 

or 

record 

unit 

begin 

else 

pairof 

recordof 

uniqueof 

bool 

if 

pdef ine 

record- set! 

vectorof 

compile 

lambda 

plambda 

ref 

vlambda 

cond 

let* 

plet* 

region 

void 

define 

let 

plet 

runion 

vsubr 

delay 

letrec 

pletrec 

select 

write 

dfunc 

load 

poly 

set) 

dlambda 

maxeff 

proj 

string 

diet* 

null 

promise 

subr 

diet 

one 

pure 

tagcase 

dletrec 

one-set! 

quote 

the 

Comments  in  FX  are  sequences  of  characters  beginning  with  a  “ ;  ”  and 
ending  with  the  end  of  line  on  which  is  located.  They  are  discarded  by 
FX  and  treated  as  a  single  whitespace. 
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The  FX  Primer 
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This  primer  is  designed  to  introduce  FX  to  you  by  way  of  a  few  representative 
programs  -  even  before  you  have  read  the  rest  of  this  manual.  We  hope  that 
this  primer  will  give  you  the  flavor  of  programming  in  FX.  We  also  hope  to 
suggest  how  larger  FX  programs  can  be  created  by  composing  elementary 
FX  expressions  together. 

Getting  Started 

In  order  to  use  FX,  start  by  invoking  the  FX  interpreter.  FX  will  prompt 
you  with  a  greeting  similar  to  this  one: 

FX  1.0  Interpreter  of  June  30,  1087 
FX  -> 

FX  is  now  ready  to  listen  to  you.  Once  you  have  typed  a  complete 
expression  and  pressed  carriage-return,  FX  will  evaluate  your  expression 
and  output  its  value.  For  example: 

FX  1.0  Interpreter  of  June  30,  1087 
FX  ->  1 

1  :  int  !  pure 
FX  »>  (♦  1  (*  2  3)) 

7  :  int  !  pure 
FX  ->  (exp  1.0) 

2.7182818  :  float  !  pure 
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FI  ->  (>  1  2) 

#1  :  bool  !  pure 

FX  prints  three  result  components  for  each  expression  that  you  type.  The 
first  component  is  the  value  of  the  expression,  the  component  after  the  “  :  * 
is  the  type  of  the  expression,  and  the  component  after  the  “  1  ”  is  the  effect  of 
the  expression.  The  type  of  an  expression  describes  its  value,  while  the  effect 
of  an  expression  describes  its  side-effects.  Thus,  types  describe  "what”  while 
effects  describe  “how” .  All  of  the  above  examples  had  effect  pure,  indicating 
that  no  side-effects  have  been  performed  by  these  computations. 

The  names  +,  *,  exp,  and  >  are  simply  variables  that  are  bound  in  the 
global  environment  to  primitive  subroutines.  You  can  bind  new  variables  to 
values  with  define: 

FI  ■>  (define  x  2) 
x  ■  2  :  lnt  1  pure 
FI  ->  x 

2  :  lnt  !  pure 
FI  ->  > 

<subr>  :  (aubr  pure  (lnt  lnt)  bool)  !  pure 

In  this  example,  the  (define  x  2)  form  introduces  a  new  variable  in 
the  global  environment  called  x  that  is  initially  bound  to  the  value  2.  By 
typing  the  expression  x  we  confirm  that  x  is  bound  to  the  value  2.  By  typing 
the  expression  >  we  see  that  >  is  bound  to  a  subroutine  (which  cannot  be 
printed,  hence  the  <subr>)  that  takes  two  integers  as  input  and  returns  a 
boolean.  The  type  of  >  includes  the  effect  that  >  will  have  when  it  is  applied. 
This  effect  is  called  the  latent  effect  of  the  subroutine;  the  latent  effect  of  > 
is  pure. 

Using  Regions  and  Effects 


4 

4 

4 

e 

1 


i 

i 

i 


Every  data  structure  in  FX  is  in  some  region.  Regions  are  useful  because  they 
enable  FX  to  perform  automatic  garbage  collection  and  to  evaluate  more 
expressions  in  parallel  than  would  otherwise  be  feasible.  Region  constants 
are  easily  recognizable  because  they  always  start  with  a  C  character.  When 
you  do  not  specify  the  region  of  a  data  structure,  the  region  C*  is  generally 
used.  Data  structures  that  .re  in  cannot  be  mutated.  You  can  choose 
the  region  of  a  data  structure  by  using  the  proj  expression  to  indicate  your 
region  choice.  For  example: 
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F X  ■>  (cons  1  2) 

(1.2)  :  (pairof  int  lnt  C-)  !  pure 

FX  ■>  (car  (cons  12)) 

1  :  lnt  !  pure 

FX  •>  (define  y  ((pro)  cons  Cgreen)  12)) 
y  -  (1  .  2)  :  (pairof  int  int  Cgreen)  !  (alloc  Cgreen) 

FX  ->  (car  y) 

1  :  int  !  (read  Cgreen) 

FX  ■>  (set-car!  y  2) 

#u  :  unit  !  (write  Cgreen) 

FX  «>  (car  y) 

2  :  int  !  (read  Cgreen) 

As  shown  in  this  example,  effects  include  region  specifications.  The  effect 
of  allocating  and  initializing  a  Cgreen  pair  is  (alloc  Cgreen) ,  the  effect  of 
reading  a  Cgreen  pair  is  (read  Cgreen) ,  and  the  effect  of  writing  a  Cgreen 
pair  is  (write  Cgreen).  Effects  on  the  region  C-  can  be  ignored  because 
data  structures  in  C»  may  not  be  mutated;  we  say  that  data  structures  in 
C»  are  immutable. 

So  far  we  have  discussed  values,  types,  regions,  and  effects.  With  these 
preliminaries  out  of  the  way,  we  can  now  consider  our  first  example  program 
-  a  recursive  implementation  of  the  Fibonacci  function: 

FI  ->  (define  (fib  (n  int)) 

(the  pure  lnt 

(cond  ((<■  n  0)  0) 

((-  n  1)  1) 

(else  (♦  (fib  (-  n  1))  (fib  (-  n  2))))))) 
fib  ■  <subr>  :  (subr  pure  (int)  lnt)  !  pure 
FX  »>  (fib  6) 

6  :  int  !  pure 

The  fib  subroutine  takes  a  single  argument  called  n  of  type  int.  The 
the  form  is  a  declaration  that  the  body  has  no  side  effects  -  it  is  pure  -  and 
that  fib  returns  an  integer. 

The  Fibonacci  function  can  also  be  programmed  with  an  iterative  imple¬ 
mentation: 

FX  ■>  (define  (iter-fib  (n  int)) 

(do  ((result  0  (♦  result  result-1)) 
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(result- 1  1  result) 

(counter  n  (-  counter  1))) 

((<■  counter  0)  result))) 

iter-fib  *  <subr>  :  (subr  pure  (int)  int)  !  pure 
FX  «>  (iter-fib  5) 

6  :  int  1  pure 

Each  clause  of  the  do  expression  provides  an  initial  value  for  a  loop 
variable  and  an  expression  for  updating  the  variable  on  each  loop  iteration. 
When  counter  is  equal  to  or  less  than  0,  result  is  returned. 

FX  gets  a  considerable  amount  of  its  power  from  the  way  that  subrou¬ 
tines  can  be  used.  In  FX,  subroutines  can  be  stored  in  data  structures, 
passed  to  other  subroutines  as  arguments,  and  returned  as  the  results  of 
subroutines.  For  example,  the  following  subroutine  compose  composes  two 
integer  subroutines: 

FX  •>  (define  (compose  (f  (subr  pure  (int)  int)) 

(g  (subr  pure  (int)  int))) 

(lambda  ((x  int))  (f  (g  x)))) 
compose  «  <subr>  :  (subr  pure  ((subr  pure  (int)  int) 

(subr  pure  (int)  int)) 

(subr  pure  (int)  int)) 

1  pure 

FX  ■>  ((compose  fib  (lambda  ((x  int))  (*  x  1)))  4) 

5  :  int  1  pure 

Polymorphism  Permits  Subroutines  to  Work  for  Many  Types 
and  Effects 

We  can  generalize  compose  so  that  it  can  work  for  subroutines  of  any  type 
by  passing  the  input  and  output  type  of  the  subroutines  as  a  special  kind  of 
argument: 

FX  ■>  (define  comp 

(plambda  ((t  type)) 

(lambda  ((f  (subr  pure  (t)  t)) 

(g  (subr  pure  (t)  t))) 

(lambda  ((x  t))  (f  (g  x)))))) 
comp  ■  <subr>  :  (poly  ( (t  type)) 

(subr  pure  ((subr  pure  (t)  t) 
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(subr  pure  (t)  t)) 

(subr  pure  (t)  t))) 

!  pure 

This  feature  of  FX  is  called  polymorphism.  (The  name  plambda  comes 
from  “Polymorphic  Lambda.”)  Polymorphism  permits  an  expression  to  be 
abstracted  over  types,  effects,  and  regions.  The  subroutine  comp  can  be 
used  in  precisely  the  same  way  as  compose  -  the  type  parameter  is  supplied 
automatically  by  FX  using  a  mechanism  called  implicit  projection.  The 
following  example  shows  how  comp  can  be  useful  on  different  types  of  values: 

FX  ■>  ((comp  fib  (lambda  ((x  int))  (+  x  1)))  4) 

5  :  int  !  pure 

FX  ■>  ((comp  not?  not?)  #t) 

#t  :  bool  !  pure 

Lists  are  Defined  with  Recursive  Types 

The  range  of  expressible  types  is  quite  large  in  FX  since  it  is  possible  to 
define  recursive  types  with  the  dletrec  special  form.  For  example,  in  FX 
the  listof  type  is  defined  in  terms  of  a  recursive  pairof  type.  A  subroutine 
that  uses  both  polymorphism  and  recusive  types  is  the  mapcar  subroutine: 

FX  »>  (define  mapcar 

(plambda  ((tl  type)  (t2  type)  (r  region)  (e  effect)) 
(lambda  ((f  (subr  e  (tl)  t2)) 

(input  (listof  tl  r))) 

(the  (maxeff  (alloc  r)  (read  r)  e) 

(listof  t2  r) 

(if  (null?  input) 

() 

((proj  cons  r) 

(f  (car  input)) 

(mapcar  f  (cdr  input)))))))) 

mapcar  ■  <subr> 

:  (poly  ((tl  type)  (t2  type)  (r  region)  (e  effect)) 
(dletrec  ((#1  (pairof  tl  #1  r)) 

(#2  (pairof  t2  #2  r))) 

(subr  (maxeff  (alloc  r)  (read  r)  e) 

((subr  e  (tl)  t2)  #1) 
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#2))) 

!  pure 

FX  ■>  (m&pcar  (lambda  ((x  int))  (+  x  1))  (list  12  3)) 

(2  3  4)  :  (dletrec  ((#1  (pairof  int  *1  «■*)))  #1)  !  pure 

Types  can  be  Abbreviated 

Because  complicated  types  may  be  cumbersome  to  write  FX  provides  a  type 
synonym  facility.  You  can  introduce  type  synonyms  in  an  expression  with 
the  plat  construct,  as  in: 

FX  ->  (define  comp 

(plambda  ((t  type)) 

(plet  ((func  (snbr  pure  (t)  t))) 

(lambda  ((f  func)  (g  func)) 

(lambda  ((x  t))  (f  (g  x))))))) 
comp  ■  <8ubr>  :  (poly  ((t  type)) 

(aubr  pure  ((subr  pure  (t)  t) 

(subr  pure  (t)  t)) 

(aubr  pure  (t)  t))) 

!  pure 

You  can  also  introduce  type  synonyms  at  top-level,  with  the  pdef  ine  top- 
level  special  form: 

FX  *>  (pdef ine  int-aubr  (subr  pure  (int  int)  int)) 
int-subr  -  (subr  pure  (int  int)  int)  type 

After  a  pdef  ine  form  is  evaluated,  the  FX  interpreter  prints  out  the 
name  of  the  variable  defined,  the  description  to  which  it  is  bound,  and  after 
the  “  ,  the  kind  of  the  variable.  Kinds  are  the  “types”  of  descriptions. 

You  can  also  define  recursive  types  at  top-level;  for  instance,  you  could 
define  the  abstract  syntax  of  a  simple  expression  language  as: 

FX  ■>  (pdef ine  expr  (oneof  ((constant  int) 

(identifier  symbol) 

(add  (pairof  expr  expr  C*))) 

«-)) 

expr  *  (dletrec  ((#1  (oneof  ((constant  int) 

(identifier  symbol) 
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(add  (pairof  #1  #1  •«))) 

«-))) 

#1)  ::  type 

Here,  oneof  is  a  standard  FX  type  constructor.  The  idea  is  that  a  value 
of  type  expr  can  be  either  an  integer  constant  (in  which  case  it  will  be 
“tagged”  by  constant),  an  identifier  represented  by  a  symbol  (yet  another 
standard  FX  type)  or  an  addition  of  two  other  expressions. 

A  Simple  Evaluator 

In  order  to  define  an  evaluator  (i.e.,  a  function  which  maps  expr  values 
to  integers)  for  our  new  tiny  language,  we  need  one  more  type  definition, 
namely  for  the  store  in  which  the  values  of  identifiers  are  kept.  Here  it  is: 

FX  *>  (pdeline  store  (subr  pure  (symbol)  int)) 
store  •  (subr  pure  (symbol)  int)  ::  type 

A  function  of  this  type  will  map  each  identifier  (recall  that  they  are  in 
fact  implemented  by  symbols)  to  its  integer  value. 

The  definition  of  our  evaluation  function  eval  is  now  easy.  It  take  two 
arguments:  an  expression  e  and  a  store  s  in  which  every  identifier  used  in  e 
has  a  value.  We  will  suppose  that  there  are  no  unbound  identifiers. 

FX  ■>  (define  (eval  (e  expr)  (s  store)) 

(the  pure  int 
(tagca8e  e 
(constant  e) 

(identifier  (s  e)) 

(add  (+  (eval  (car  e)  s) 

(eval  (cdr  e)  s)))))) 

eval  »  <subr> 

:  (dletrec  ((#1  (oneof  ((constant  int) 

(identifier  symbol) 

(add  (pairof  #1  #1  €**))) 

«-))) 

(subr  pure 

(#1  (subr  pure  (symbol)  int)) 
int)) 

!  pure 
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The  eval  function  is  a  pure  subroutine  which  maps  an  expr,  which  is 
represented  by  the  complicated  recursive  type  #1,  and  a  Btore  to  a  vake  of 
type  int. 

The  tagcase  special  form  is  used  to  dispatch  on  a  oneof  value  according 
to  its  tag.  Inside  each  clause  of  such  a  form,  the  variable  e  denotes  the 
contents  of  the  oneof  value;  for  instance,  inside  the  identifier  clause,  e 
represents  the  symbol  corresponding  to  the  identifier  value.  This  is  why 
we  apply  the  store  s  to  e  to  get  its  integer  value.  It  is  also  interesting  to 
note  that  the  recursive  calls  to  eval  used  to  compute  the  addends  of  an  add 
expression  have  no  side-effects  (the  eval  function  is  pure).  Therefore,  the 
FX  compiler  may  schedule  them  to  run  in  parallel  safely. 

Let  us  check  that  our  definition  works. 


FX  *>  (define  x-plua-1  (one  expr  add 

(cons  (one  expr  identifier  ’x) 
(one  expr  constant  1)))) 
x-plus-l  *  (add  (identifier  .  x)  constant  .  1) 

:  (dletrec  ((*1  (oneof  ((constant  int) 

(identifier  symbol) 

U.  (pairof  #1  #1  •«))) 

•-))) 

#1) 


!  pure 

FX  •>  (eval  x-plus-l  (lambda  ((s  synbol)) 

(if  (eq?  s  »x)  30))) 

4  :  int  !  pure 


We  first  define  the  expression  x-plus-l  corresponding  to  the  addition 
of  the  identifier  ’x  (symbol  literals  are  distinguished  by  the  use  of  a  quote 
character)  and  the  constant  1;  one  is  the  special  form  defined  in  FX  to 
construct  an  value  whose  type  is  a  oneof.  The  real  test  is  then  to  evaluate 
x-plus-l  in  a  store  which  binds  ’x  to  the  value  3;  the  result  is,  of  course, 
4. 


Effects  can  be  Masked 

Effects  that  are  not  observable  outside  of  an  expression  can  be  masked  by  the 
effect  system.  For  example,  an  assignment  to  a  formal  subroutine  parameter 
may  not  be  reported  as  part  of  the  latent  effect  of  the  subroutine  if  it  cannot 
be  observed  by  the  caller: 
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FX  ■>  (deline  (1  (x  int  Clocal)) 

(set!  x  (♦  x  1)) 

(*  x  x)) 

F  ■  <subr>  :  (subr  pure  (int)  int)  !  pure 
FX  ->  (f  10) 

121  :  int  !  pure 

Similarly,  a  subroutine  that  constructs  a  circular  list  has  only  an  alloc 
effect,  even  though  it  mutates  the  list  after  allocating  it,  because  this  muta¬ 
tion  cannot  be  observed  by  the  caller: 

FX  ■>  (define  circular- list 

(plambda  ((r  region)) 

(plambda  ((t  type)) 

(lambda  ((init  t)) 

(let  ((1  ((proj  list  r)  init))) 

(set-cdr!  1  1) 

1))))) 

circular- list  *  <subr> 

:  (poly  ((r  region)) 

(poly  ((t  type)) 

(dletrec  ((#1  (pairof  t  #1  r))) 

(subr  (alloc  r)  (t)  #1)))) 

I  pure 

fx>  (lambda  ()  ((proj  circular-list  Qgreen)  5)) 

<8ubr>  :  (dletrec  ((#1  (pairof  int  #1  Qgreen))) 

(subr  (alloc  Qgreen)  ()  *1)) 

!  pure 

fx>  (lambda  ()  (circular-list  5)) 

<subr>  :  (dletrec  ((#1  (pairof  int  #1  Q-))) 

(subr  pure  ()  #1)) 

!  pure 

As  this  example  shows,  the  effect  of  creating  a  Qgreen  circular  list  is 
(alloc  Qgreen),  and  the  effect  of  creating  an  immutable  circular  list  is 
pure.  Effect  masking  is  more  thoroughly  described  in  Section  2.3. 
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Thir  ends  our  short  primer  on  FX.  We  hope  that  you  have  a  sense  of 
how  the  FX  language  can  be  used.  The  best  way  to  learn  more  about  FX 
is  to  try  writing  a  few  programs.  The  rest  of  this  manual  contains  all  of  the 
information  that  you  need  to  write  programs  on  your  own. 


Have  fun,  and  good  effects! 
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Chapter  2 


The  FX  Kernel 


The  FA*  Kernel  ia  a  simple  programming  language  that  is  the  basis  of  the 
FX  programming  language.  All  of  the  constructs  in  the  FX  language  can 
be  directly  explained  by  rewriting  them  into  the  simpler  FX  Kernel  lan¬ 
guage.  Thus,  the  FX  Kernel  forms  the  core  of  the  FX  language  from  the 
point  of  view  of  both  the  FX  application  programmer  and  the  FX  language 
implementor. 

The  FX  Kernel  has  three  language  levels  each  with  its  own  set  of  expres¬ 
sions:  value  expressions,  description  expressions  and  kind  expressions.  In 
the  simplest  terms,  programs  are  value  (or  ordinary)  expressions,  types  are 
descriptions,  and  kinds  are  the  “types  of  types” . 


•  Value  expressions  form  the  lowest  level  of  the  language.  Programs  and 
literals  (e.g.  #t)  are  examples  of  value  expressions. 


•  Descriptions  form  the  second  level  of  the  language.  There  are  four 
kinds  of  descriptions:  region,  effect,  type  descriptions  and  description 
functions.  As  the  name  suggests,  descriptions  describe  value  expres¬ 
sions  -  in  particular,  every  legal  value  expression  has  both  a  type  and 
an  effect  description.  Region  descriptions  are  used  as  components  of 
effect  descriptions. 


Kinds  form  the  third  and  highest  level  of  the  language.  Kinds  are  the 
“types”  of  descriptions,  and  every  legal  description  expression  has  a 
kind. 


FX  is  a  block-structured,  lexically-scoped  language,  like  Scheme  or  Com- 
monLISP.  Whenever  a  variable  is  used,  it  refers  to  the  inner-most  lexical 
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binding  of  that  variable.  A  variable  may  stand  for  a  description  or  a  value, 
but  may  not  be  bound  simultaneously  to  both  a  description  and  a  value. 


2.1  Kind  Expressions 

2.1.1  Meta-notation  for  Kinds 

Kind  expressions  have  the  meta-notation  Kexp.  A  kind  expression  is  either 
a  kind  constant  or  a  kind  constructor  expression. 

To  express  the  idea  that  a  description  expression  has  Borne  kind,  we  use 
a  double  colon. 


Dexp  ::  Kexp 

should  be  read:  “The  description  expression  Dexp  has  kind  Kexp.”  We  will 
at  times  avail  ourselves  of  the  shorthand  notation 

Dexpi,. . .  ,Dexpn  ::  Kexp 

to  mean  that  each  of  the  Dexpt  (1  <  i  <  n)  is  of  kind  Kexp. 

2.1.2  Kind  Constants 
FX  has  three  kind  constants: 

•  region  is  the  kind  of  a  description  which  describes  an  area  of  memory 

(e.g.  ::  region). 

•  effect  is  the  kind  of  a  description  which  describes  the  side-effects  of 
a  computation  (e.g.  pure  ::  effect). 

•  type  is  the  kind  of  a  description  which  describes  a  set  of  values  (e.g. 
bool  ::  type). 

2.1.3  Kind  Constructors 

dfunc  expressions  provide  a  way  to  build  new  kinds;  dfunc  is  a  kind  con¬ 
structor. 


(dfunc  {Kexpv  . .  Kexpn)  Kexp) 


2.2.  Description  Expressions 


Kinds  built  with  dlunc  are  the  kinds  of  description  functions  which  map 
descriptions  to  descriptions.  A  description  function  which  returns  a  type  is 
called  a  type  constructor  because  it  provides  a  way  to  build  a  new  type  ( e.g ., 
rei  ::  (dlunc  (type  region)  type)).  Effect  and  region  constructors  arise 
in  the  same  way. 

One  creates  description  functions  with  the  dlambda  description  special 
form  described  on  page  23.  One  uses  description  functions  by  applying  them 
as  described  on  page  24. 


2.2  Description  Expressions 

Description  expressions  are  used  to  describe  FX  values  and  program  expres¬ 
sions.  Every  legal  description  expression  has  a  kind  (e.g.  the  description 
expression  (rel  bool  €■)  has  kind  type.) 

2.2.1  Meta-notation  for  Descriptions 

Description  variables  have  the  meta-notation  d,  and  description  expressions 
have  the  metar notation  Dexp. 

2.2.2  Variables 

The  programmer  may  use  any  unreserved  identifier  as  a  description  variable. 
(See  page  xiii  for  a  list  of  reserved  identifiers.) 

A  description  variable  denotes  the  description  it  is  bound  to  in  the  sur¬ 
rounding  bindings. 

2.2.3  Regions 

A  region  represents  a  set  of  locations  in  the  store.  The  programmer  may 
think  of  a  region  as  an  area  of  memory  (though  a  region  may  not  actually 
be  a  contiguous  set  of  memory  locations).  The  compiler  may  use  regions  to 
determine  whether  two  program  expressions  interfere,  i.e.  whether  they  may 
cause  and/or  observe  changes  to  common  data.  Since  one  cannot  determine 
interference  patterns  exactly  for  every  data  value  without  running  the  pro¬ 
gram,  the  FX  compiler  makes  the  conservative  assumption  that  expressions 
with  side  effects  (see  below)  in  the  same  region  do  interfere. 
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Meta-notation  for  Regions 

The  meta-notation  for  description  variables  of  kind  region  is  r.  Region 
expressions  have  the  meta-notation  Rexp.  A  region  expression  is  a  region 
variable,  a  region  constant,  or  a  region  constructor  expression. 

Region  Constants 

All  region  constants  begin  with  the  special  character  Q  (read  “at”).  There 
is  one  special  region  called  the  immutable  region  whose  name  is  (read 
“at-equal”  or  “the  immutable  region”).  This  region  has  the  property  that 
values  in  it  can  never  be  changed.  There  is  an  infinite  supply  of  other  region 
constants  which  are  mutable;  their  names  are  of  the  form  Cidentifier.  All 
region  constants  denote  disjoint  sets  of  locations. 

Region  Constructors 

The  only  operation  on  regions  is  run!  on. 


ranion 


region  expression 


(rani  on  Rexpl  Rexp 2. . . ) 

Semantics:  The  ranion  operation  forms  the  set  union  over  all  the  regions 
denoted  by  the  Rexpt  ;  the  result  is  a  region.  The  ranion  of  just  one  region 
is  equivalent  to  that  region. 

ranion  expressions  are  flattened,  i.e.  inner  ranion  expressions  are  re¬ 
placed  with  the  regions  of  the  set  to  which  they  correspond.  Duplicates  are 
ignored  and  order  is  not  significant.  For  example,  (ranion  Ca  (ranion  Ga 
Ob)  )  is  equivalent  to  (ranion  Cb  Ga) . 

Kind  Information:  The  kind  of  an  ranion  expresssion  is  region. 
Example: 

;;  Composing  "colored”  regions. 

i  * 

(ranion  Gblne  Gred  Gyellow) 
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2.2.4  Effects 

The  effect  of  an  expression  is  a  static  description  of  the  observable  store 
operations  which  may  be  performed  during  the  evaluation  of  the  expression. 
Store  operations  performed  by  an  expression  are  observable  when  they  are 
performed  on  store  locations  that  are  accessible  outside  of  the  scope  of  the 
expression. 

FX  uses  effects  to  discover  expression  scheduling  constraints.  FX  will 
constrain  two  expressions  to  be  executed  serially  only  if  the  expressions  in¬ 
terfere  with  one  another.  Two  program  expressions  interfere  if  one  expression 
writes  a  region  of  the  store  that  the  other  expression  reads  or  writes. 

FX  also  uses  the  property  that  expressions  with  the  pure  effect  are  ref- 
erentially  transparent.  Informally  speaking,  an  expression  is  referentially 
transparent  if  two  occurances  of  the  expression  in  the  same  scope  can  be 
replaced  by  a  single  instance  of  the  expression.  Thus,  when  an  expression  is 
referentially  transparent  both  static  common  subexpression  elimination  and 
dynamic  memoization  can  be  applied  to  it. 

Meta-notation  for  Effects 

Effect  variables  have  the  meta-notation  e,  and  effect  expressions  have  the 
meta- notation  Eexp.  An  effect  expression  is  an  effect  variable,  a  simple 
effect,  or  an  effect  constructor  expression. 

Simple  Effects 

FX  describes  effects  in  terms  of  three  sorts  of  operations  on  the  store: 

•  One  may  allocate  and  initialize  a  location  in  the  store,  e.g.  by  making 
a  binding  for  a  variable  in  some  region. 

•  One  may  read  a  location  in  the  store,  e.g.  by  referencing  a  variable  in 
some  region. 

•  One  may  write  a  location  in  the  store,  e.g.  by  assigning  to  a  variable 
in  some  region. 

The  corresponding  effects  on  a  region  Rezp  are  written: 

(alloc  Rezp) 

(read  Rezp) 

(write  Rezp) 
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An  expression  which  has  no  effect  or  dependence  on  the  store  is  said  to  have 
effect  pure. 

Recall  that  the  special  region  €■  is  immutable.  Therefore,  it  is  a  static 
effect  error  for  an  expresion  to  have  effect  (write  •■).  Since  no  value  in  the 
immutable  region  may  ever  be  changed,  the  operations  of  allocating  in  and 
reading  from  0*  cannot  be  observed.  Thus,  (alloc  C«)  and  (read  fl«)  are 
both  equivalent  to  pure. 


Effect  Constructors 


The  only  operation  on  effects  is  naxeff . 


maxelf 


effect  expression 


(maxelf  Eezpx  . . . ) 

Semantics:  The  maxelf  operation  can  be  thought  of  as  constructing  the 
set  or  combination  of  all  effects  corresponding  to  the  effect  expressions  sup¬ 
plied  as  arguments;  the  result  is  an  effect.  The  maxelf  of  just  one  effect  is 
equivalent  to  that  effect. 

maxelf  expressions  are  flattened  in  the  same  way  as  reunion  expres¬ 
sions;  inner  maxelf  expressions  are  replaced  with  the  effects  from  the  set 
to  which  they  correspond.  Duplicates  are  ignored  and  order  is  not  signifi¬ 
cant.  The  simpler  expression  pure  is  an  abbreviation  for  the  empty  set  of 
effects  (maxelf). 

The  simple  effects  have  a  distributive  property  over  runion.  For  instance, 
(alloc  (runion  6a  6b))  can  be  rewritten  (maxelf  (alloc  6a)  (alloc  6b)). 
We  will  always  use  this  latter  version. 

Kind  Information:  The  kind  of  a  maxelf  expression  is  effect. 
Example: 

; ;  The  most  complex  effect  on  61 oo. 

»  i 

(maxelf  (alloc  6foo)  (read  61 oo)  (write  61oo)> 
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2.2.5  Types 

In  FX,  a  type  denotes  a  collection  of  values.  A  value  has  some  particular 
type  if  it  is  in  the  collection  of  values  denoted  by  the  type. 

Meta-notation  for  Types 

Type  variables  have  the  meta-notation  t.  Type  expressions  have  the  meta¬ 
notation  Texp.  A  type  expression  is  a  type  variable,  a  type  constant,  or  a 
type  constructor  expression. 

Type  Constants 
The  builtin  types  are: 

bool  the  type  containing  the  two  boolean  values  #t  and  #f  for  true  and 
false.  The  type  of  the  predicate  of  a  conditional,  i.e.  if,  is  bool. 

unit  the  type  containing  the  single  value  #u.  The  unit  type  is  useful  as  the 
return  type  of  subroutines  which  are  called  solely  for  their  side-effects 
and  which  do  not  compute  a  useful  return  value. 

Type  Constructors 

There  are  three  builtin  ways  to  build  new  types  from  old  ones.  They  are 
described  on  the  following  pages:  subr,  poly  and  ref. 


type  expression 


(subr  Eexp  ( Texp1. . .)  Texp) 


Semantics:  This  is  the  type  of  a  subroutine  created  by  the  lambda  expres¬ 
sion. 

Eexp  is  the  latent  effect  of  the  subroutine;  that  is,  upon  application,  eval¬ 
uation  of  the  subroutine  will  have  an  effect  of  Eexp.  The  Texp,  are  the  types 
of  the  parameters.  Texp  is  the  type  of  the  value  which  the  subroutine  will 
return.  (See  the  descriptions  of  lambda  on  page  34  and  ordinary  application 
on  page  36.) 

Kind  Information:  The  kind  of  a  subr  expression  is  type. 

Example: 

;;  The  type  of  the  Identity  function  on  booleana. 

•  i 

(subr  pure  (bool)  bool) 
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poly 


type  expression 


(poly  (( d\  Kezp *)...)  Tezp) 

The  di  must  all  be  distinct. 

Semantics:  This  is  the  type  of  a  polymorphic  value  created  by  the  plambda 
expression. 

The  description  variables  di  are  bound  variables;  their  kinds  are  given 
by  the  Kezpi.  When  a  polymorphic  value  is  projected  (either  explicitly  or 
implicitly),  the  description  arguments  are  bound  to  the  di  and  the  result  of 
the  projection  is  a  value  whose  type  is  Tezp  with  the  di  substituted  by  the 
corresponding  description  arguments.  (See  the  descriptions  of  the  plambda 
expression  on  page  39,  projection  on  page  40  and  implicit  projection  on  page 
41.) 

Kind  Information:  The  kind  of  a  poly  expression  is  type. 

Example: 

; ;  The  type  of  the  polymorphic  identity  function. 

»  » 

(poly  ((t  type)) 

(subr  pure  (t)  t)) 
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The  type  of  a  value  which  is  a  reference  to  a  location  in  region  Rexp 
containing  a  value  of  type  Texp  is: 

(rei  Texp  Rexp )  ::  type 

The  kind  of  ref  is: 


ref  ::  (dfunc  (type  region)  type) 

2.2.6  General  Description  Expressions 

There  are  three  description  expressions  which  provide  general  ways  of  ma¬ 
nipulating  descriptions  (of  any  kind).  These  expressions  are  used  to  define 
and  apply  description  functions,  and  to  build  recursive  descriptions.  These 
expressions  are  described  on  the  following  pages:  dlambda,  Description  Ap¬ 
plication  and  dletrec. 
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dlambda 


description  expression 


(dlambda  ((di  Kexpl)...{dn  Kexpn))  Dcxpbody) 

The  di  must  all  be  distinct. 

Semantics:  Just  as  lambda  provides  a  means  of  abstracting  program  code 
over  ordinary  variables  to  make  subroutines,  the  dlambda  description  ex¬ 
pression  provides  a  means  of  abstracting  a  description  expression  over  de¬ 
scription  variables  to  make  description  functions.  (See  also  the  definition  of 
description  application  on  page  24.) 

Kind  Information:  The  kind  of  a  description  function  created  with 
dlambda,  assuming  that  the  kind  of  Dexpbody  is  Kexpbody ,  is: 

(dfunc  (Kexp1...)  Kexpbody) 


Examples: 

; ;  An  effect  constructor  which  is  abstracted  over  a  region. 

I  » 

(dlambda  ((r  region)) 

(maxeff  (alloc  r)  (read  r)  (write  r))) 

; ;  A  constructor  of  types  of  subroutines  which  have 
; ;  every  possible  side  effect  on  some  region.  The  caller 
; ;  should  specify  the  argument  type  (there  is  only  one 
;;  argument)  and  the  return  type  of  the  subroutine. 

(dlambda  ((arg-type  type)  (ret-type  type)  (r  region)) 

(subr  (maxeff  (alloc  r)  (read  r)  (write  r)) 
(arg-type) 
ret-type) ) 
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Description  Application 


description  expression 


(Dexpf 

unc  Dexpl. . .) 


Semantics:  Dezpj unc  must  evaluate  to  a  description  function  (see  the  de¬ 
scription  of  dlambda  on  page  23).  In  particular,  the  kind  of  Dexpjune  must 
be  (dfunc  (Kexp1. . Kexp^odv).  The  Dexpi  are  the  actual  parameters,  or 
arguments,  to  the  function.  Each  argument  expression  must  be  of  the  proper 
kind;  i.e.  Dexpi  must  be  of  kind  Kexp(.  The  number  of  actual  parameters 
must  be  the  same  as  the  number  of  formal  parameters.  When  the  description 
function  is  applied  to  its  arguments,  the  description  expression  which  is  its 
body  is  returned  with  the  arguments  substituted  for  the  formal  parameters. 

Kind  Information:  The  kind  of  a  description  application  is  KexpMy,  the 
kind  of  the  body  of  the  dlambda  form  which  defines  the  description  function. 

Examples: 

;;  A  synonym  for  the  type  of  the  identity  function  on  booleans. 
•  • 

((dlambda  ((t  type)) 

(subr  pure  (t)  t)) 

bool) 

;;  A  complicated  effect. 

■  i 

((dlambda  ((r  region)) 

(maxeff  (alloc  r)  (read  r)  (write  r))) 

(runion  Cgreen  Cblue  Cred  Cpurple) ) 


dletrec 


description  expression 


(dletrec  ((di  DexpJ...)  Dexphody) 

The  di  must  all  be  distinct. 

Semantics:  First,  all  of  the  di  are  made  available.  Then,  the  Dexpi  are 
successively  evaluated  and  bound  to  the  corresponding  di.  This  order  is  im¬ 
portant  because  it  allows  any  of  the  Dexpj  to  refer  to  some  d,,  thus  providing 
for  mutual  recursion.  This  process  is  subject  to  the  following  restriction:  all 
description  variables  that  can  be  recursively  reached,  in  the  graph  of  de¬ 
scription  variable  usage,  from  an  expression  Dexpi  must  be  defined  before 
the  processing  of  the  binding  for  di,  unless  their  kinds  are  type.  Typically, 
the  Dexpj  are  recursive  type  descriptions  and  so  there  is  no  problem.  It 
is  a  static  type  error  if  any  of  the  di  is  defined  as  itself,  either  directly  or 
indirectly. 

The  value  of  the  dletrec  expression  is  the  body,  Dexpiody,  evaluated 
with  the  (possibly  recursive)  definitions  of  the  di  substituted  for  the  d,-. 

Kind  Information:  The  kind  of  a  dletrec  description  special  form  is  the 
kind  of  Dexphody . 

Example: 

; ;  Example  of  list . 

i  t 

(dletrec  ((list-bool  (pairof  bool  list-bool  Cbool))) 
list-bool) 


t 

I 

; 
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2.2.7  Description  Inclusion 

Some  description  expressions  are  more  constrained  versions  of  others.  A 
more  constrained  description  is  said  to  be  included  in  (a  subdescription  of) 
the  less  constrained  one.  For  instance,  a  region  is  a  set  of  memory  locations. 
If  every  location  in  one  region  is  also  in  another,  then  the  first  is  a  subregion 
of  the  second,  and  is  said  to  be  included  in  the  second.  We  can  also  define 
subeffects  and  subtypes.  Two  description  expressions  are  interconvertible  if 
and  only  if  each  is  included  in  the  other;  two  description  expressions  that 
are  interconvertible  denote  the  same  description. 

One  description  expression  can  only  be  a  subdescription  of  another  if 
both  are  of  the  same  kind:  a  type  cannot  be  included  in  a  region  since  types 
and  regions  describe  different  things. 

The  least  upper  bound  of  a  set  of  descriptions  of  the  same  kind  is  the 
least  description  of  that  kind  that  includes  all  the  members  of  the  set.  The 
runion  operation  computes  the  least  upper  bound  of  a  set  of  regions,  and 
maxeff  computes  the  least  upper  bound  of  a  set  of  effects.  No  least  upper 
bound  operation  is  provided  for  types  because  certain  sets  of  types  do  not 
have  a  least  upper  bound. 

The  maximum  description  of  a  set  of  descriptions  (all  of  the  same  kind) 
is  the  element  of  the  set  that  includes  all  the  members  of  the  set.  Since  not 
every  set  of  descriptions  has  a  maximum,  FX  provides  no  way  to  express  the 
maximum  of  a  set  of  descriptions. 


Region  Inclusion 

Recall  that  runion  expressions  are  canonicalized  (by  flattening)  and  that 
the  runion  of  one  region  is  equivalent  to  this  region. 

The  region  denoted  by  Rexp^  is  a  subregion  of  the  region  denoted  by 
Rexp2  iff  (if  and  only  if)  the  set  of  regions  in  Rexpx  is  a  subset  of  the  set  of 
regions  in  Rexp2. 


Effect  Inclusion 

Recall  that  maxeff  expressions  are  canonicalized  (by  flattening)  and  that 
the  maxeff  of  one  effect  is  equivalent  to  this  effect. 

These  rules  depend  upon  the  rules  for  region  inclusion: 

•  pure  is  a  subeffect  of  any  other  effect  and  is  a  shorthand  for  (maxeff). 


26 


2.2.  Description  Expressions 


•  (alloc  Rexp2)  is  included  in  (alloc  Rexp 2)  iff  Rexp2  is  included  in 
Rexp2.  The  analogous  rules  hold  for  read  and  write. 

•  (maxeif  Eexpn . .  .Eexpln)  is  included  in  (maxeff  Eexp21. .  .Ecxp2m)  iff 
every  Eexpu  is  contained  in  some  Eexp2j. 


Type  Inclusion 

There  is  no  inclusion  between  the  base  types  bool  and  unit.  So  we  need 
only  describe  the  way  inclusion  works  with  respect  to  the  type  constructors: 

•  Suppose 


*1  s  (*»ubr  Ecxpl(Texpn  . . .  Texpln)  Texplrtn) 
t2  =  (snbr  Eexp2(Texp21 . . .  Texp2m)  Texp2rtn) 

ti  is  a  subtype  of  t2  iff 

1.  m  =  n, 

2.  Eexpi  is  a  subeffect  of  Eexp2, 

3.  Texp2i  is  a  subtype  of  Texpu  (for  1  <  *  <  n),  and 

4.  Texplrtn  is  a  subtype  of  Texp2rtn. 

Notice  that  if  tj  is  a  subtype  of  t2,  then  the  types  of  the  arguments  of 
*1  are  supertypes  of  the  types  of  the  arguments  of  t2. 

Rationale:  Imagine  a  program  being  passed  a  subroutine  as  an  argu¬ 
ment.  If  you  pass  such  a  program  a  subroutine  whose  type  is  a  subtype 
of  the  expected  one,  the  program  should  still  be  able  to  work  properly 
since  the  program  could  handle  the  larger  type.  The  effect  cannot  be 
larger  than  originally  expected;  the  program  should  still  be  able  to 
pass  the  subroutine  at  least  the  same  argument  types  as  expected  (one 
may  extend  the  set  of  arguments  accepted  but  may  not  restrict  it);  and 
the  subroutine  should  return  a  subtype  of  the  return  type  expected  so 
that  the  calling  program  can  handle  the  result. 

•  Suppose 


1 1  =  (poly  ((d11Kexp11)...(dlnKexpln))Texp1) 

t2  =  (poly  ((d2iKexp21) . .  .(d2mKexp2m))Texp2) 
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ti  can  only  be  a  subtype  of  fj  if  n  =  m.  The  particular  names  chosen 
for  formal  parameters  do  not  matter,  so  we  can  pick  new  unused  names 
d\  ...  dn'  and  substitute  di  for  du  in  Texpx  and  for  da  in  Tezpj.  This 
process  of  renaming  bound  variables  with  unused  names  is  called  alpha- 
coaversion. 

Then,  ti  is  a  subtype  of  t j  iff 

1.  Kexpu  =  Kexpa  (for  1  <  «  <  n)  and 

2.  Texpi  is  a  subtype  of  Texpj. 

•  Suppose 


ti  =  (ref  TexfiRexpi) 
tj  =  (ref  TexfaRexpj) 

ti  is  a  subtype  of  <2  iff  either 

X.  Rexpx  is  a  subregion  of  Rexp^  and  Texp1  is  interconvertible  with 
Tezpt,  or 

2.  Rexpl  —  Rexp-i  =  •«  and  Tzxpx  is  a  subtype  of  Terpj. 

Rationale:  Consider  a  subroutine  which  expects  an  argument  of  some 
reference  type.  If  the  subroutine  expects  the  reference  to  be  in  a  muta¬ 
ble  region,  then  it  is  perfectly  reasonable  for  the  subroutine  to  write  to 
the  location  denoted  by  the  reference.  Now  if  we  pass  this  subroutine  a 
reference  to  a  value  of  some  subtype  of  the  expected  type,  the  subrou¬ 
tine  could  mutate  the  reference  so  that  it  refers  to  a  value  of  a  larger 
type  (namely  the  type  specified  inside  the  expected  reference  type). 
But  this  would  be  a  type  error!  Therefore,  we  require  the  type  parts 
of  mutable  references  to  be  interconvertible  in  the  subtyping  rules. 

The  assignment  problem  cannot  arise  if  the  reference  is  located  in  the 
immutable  region  €■;  the  natural  subtyping  rule  applies  here. 


General  Description  Inclusion 

Notice  that  the  following  inclusion  rules  are  symmetric.  That  is  if  one  de¬ 
scription  function  or  description  application  is  included  in  another,  then  the 
two  are,  in  fact,  interconvertible. 
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•  Suppose 

/  =  (dlaabda  ((di  Kexpb)  ...(dn  Kexpn))  ( Dexp  db  . . .  dn)) 

Then  /  is  interconvertible  with  Dexp  iff  none  of  the  d,  occurs  unbound 
in  Dexp.  This  rule  is  called  eta-conversion. 

•  Suppose  we  have  the  two  description  functions 

fi  =  (dlaabda  ((dn  Kexpn) . .  .(dln  Kexpln))  Dexpbodyl) 

/a  =  (dlaabda  ((dai  Kexp3l)  .  ..{d2m  Kexpim ))  Dexpbody 2) 

fi  is  included  in  /a  iff 

1.  n  =  m, 

2.  Kexpu  =  Kexp3i  (for  1  <  »  <  n),  and 

3.  Dcxpbodyl  is  interconvertible  with  Dexpbody3  after  alpha-conversion. 
(Alpha-conversion  is  defined  on  page  28.) 

•  Suppose  we  have  the  two  description  applications 

di  =  (Dezpn  Dexpl3  . .  Dexpln) 
d3  =  {Dexp2l  Dexp33  . . .  Dexp3m) 


di  is  included  in  d3  iff 

1.  n  =  m  and 

2.  Dexpu  is  interconvertible  to  Dexp3i  (for  1  <  *  <  n). 

2.3  Value  Expressions 

Value  expressions  are  the  bottom  of  our  language  hierarchy;  this  is  where 
the  actual  computation  gets  done. 
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2.3.. 1  Meta-notation  for  Value  Expressions 

Ordinary  variables  (variables  denoting  actual  computational  values  rather 
than  descriptions)  have  the  meta-notation  var.  Ordinary  expressions,  or 
value  expressions,  have  the  meta-notation  exp.  A  value  expression  is  an 
ordinary  variable,  a  builtin  literal  or  a  compound  expression. 

We  often  want  to  express  the  fact  that  a  value  expression  or  a  set  of  value 
expressions  has  some  type.  (Just  as  we  wanted  to  express  that  a  description 
expression  had  a  kind.  See  page  12.) 

exp  :  Texp 
expt,. . .  ,expn  :  Texp 

This  notation  means  that  exp  has  type  Texp  or,  in  the  second  case,  that  each 
expi  is  of  type  Texp. 

We  also  want  to  express  the  fact  that  a  value  expression  or  a  set  of  value 
expressions  has  some  effect. 

exp  !  Eexp 
explt...,expn  !  Eexp 

This  notation  means  that  exp  has  effect  Eexp  or,  in  the  second  case,  that 
each  expi  has  effect  Eexp. 

2. 3. . 2  Effect  Masking 

The  effect  of  a  value  expression  derives  from  operations  that  the  expression 
performs  on  the  store:  i.e.  allocating,  reading,  and  writing.  But  even  if  a 
value  expression  performs  certain  operations  on  the  store,  the  compiler  may 
be  able  to  prove  that  those  operations  cannot  interfere  with  other  expres¬ 
sions.  If  this  is  the  case,  then  the  effect  system  will  mask  effects  which  derive 
from  those  operations.  For  example,  an  assignment  to  a  formal  subroutine 
parameter  need  not  be  reported  as  part  of  the  latent  effect  of  the  subroutine 
since  it  alters  a  part  of  the  store  known  only  to  an  invocation  of  the  sub¬ 
routine  and  thus  cannot  interfere  with  expressions  outside  of  the  subroutine. 
The  rule  for  effect  masking  is: 

If  a  value  expression  has  effects  on  some  region  r,  and  if  r  does  not 
appear  in  the  type  of  any  free  ordinary  variables  in  the  expres¬ 
sion,  then  any  read  or  write  effect  on  r  is  masked;  furthermore, 
if  r  does  not  appear  in  the  type  of  the  whole  expression,  then 
any  alloc  effect  on  r  is  also  masked. 
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2.3.  Value  Expressions 


A  variable  is  free  in  a  value  expression  if  it  appears  in  but  is  not  bound 
in  the  expression.  See  Appendix  B  for  a  formal  definition  of  free  variables. 

2.3.1  Builtin  Literals 

The  builtin  constants  are  ft  for  the  boolean  value  true,  #f  for  the  boolean 
value  false,  and  #u  for  the  single  value  of  type  unit  (signifying  “nothing”  or 
“done” ) . 

As  expressions,  they  evaluate  to  themselves  and  have  a  pure  effect. 

2.3.2  Variables 

The  programmer  may  use  any  unreserved  identifier  as  a  variable.  (See  page 
xiii  for  a  list  of  reserved  identifiers.)  When  a  variable  is  introduced  in  a 
letrec  or  lambda  expression,  the  programmer  may  specify  that  the  value 
corresponding  to  the  variable  will  be  in  some  region.  If  no  region  is  specified, 
the  value  is  assumed  to  be  in  the  region  C“.  If  a  variable  is  in  region  C“, 
then  the  value  of  that  variable  may  not  be  changed,  i.e.  may  not  be  the  first 
argument  toaattl  expression. 

A  variable  evaluates  to  the  value  it  denotes  and  has  a  read  effect  on  the 
region  where  it  is  located,  which  reduces  to  pure  if  the  region  is  C*». 

2.3.3  Compound  Expressions 

The  following  pages  document  the  compound  expressions  (or  special  forms) 
defined  by  the  FX  kernel.  Each  compound  expression  performs  some  compu¬ 
tation  and  returns  a  value.  Hence,  these  expressions  are  called  value  expres¬ 
sions:  begin,  the,  lambda,  Application,  letrec,  plambda,  proj,  Implicit 
Projection,  plet,  pletrec,  if  and  set!. 


vv 


begin 


value  expression 


(begin  expx  exp,. . .  e*pn) 


Semantics:  The  expressions  in  a  begin  expression  are  evaluated  in  order, 
left  to  right.  The  value  of  the  begin  expression  is  the  value  of  the  last 
expression,  expn. 

Type  Information:  The  type  of  a  begin  expression  is  the  type  of  the  last 
expression,  expn. 

Effect  Information:  The  effect  of  a  begin  expression  is  computed  by  per¬ 
forming  effect  masking  on  the  maxef  f  of  the  effects  of  the  expressions  in  the 
sequence,  the  exp, . 

Example: 

; ;  Call  loo  and  then  bar  (which  probably  have 
;;  side -effects) .  Return  the  value  returned  by  bar. 

(begin  (foo) 

(bar)) 
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the  expressions  provides  a  way  to  declare  the  type  or,  possibly,  the  effect 
of  some  value  expression. 

the  expressions  are  useful  as  a  form  of  documentation  or  as  a  means 
of  coercing  exp  to  a  higher  effect  and/or  to  a  supertype  of  its  actual  type. 
One  might  make  use  of  this  feature  to  prevent  code  from  depending  on  the 
current  return  value  of  a  stub  subroutine,  i.e.  the  can  be  used  to  assert 
that  the  subroutine  has  a  particular  return  type  and  effect  which  is  more 
complicated  than  the  real  type  and  effect,  (the  is  not  a  type  loophole.) 

Semantics:  The  value  of  a  the  expression  is  the  value  exp.  exp  must  have 
a  type  which  is  a  subtype  of  Texp  and  an  effect  less  than  or  equal  to  Eexp 
(if  Eexp  is  given). 

Type  Information:  The  type  of  a  the  expression  is  Texp. 

Effect  Information:  The  effect  of  a  the  expression  is  Eexp  if  it  is  supplied. 
Otherwise,  it  is  the  effect  of  exp. 

Example: 

;;  Simulates  a  write  effect  on  Cfoo. 

•  9 

(the  (write  Cfoo)  int  0) 


lambda 


value  expression 


(lambda  ((varx  Texpx  (flexpx))- . .  (warn  Texpn  [#expn])) 
expi  exp2. . .  expm) 

The  body  of  the  lambda  expression,  exp1  exp2. . .  expm,  is  treated  as 
though  (begin  expx  exp2. .  -expm)  is  written. 

The  war,  must  all  be  distinct. 

Semantics:  lambda  provides  a  way  of  abstracting  program  expressions  over 
ordinary  variables  to  make  a  subroutine  value  or  closure  which  is  the  value 
of  the  lambda  expression.  The  subroutine  takes  n  arguments  and,  when 
applied  to  n  arguments  each  of  the  proper  type,  i.e.  the  type  of  argument 
»  is  a  subtype  of  Texpit  returns  the  value  of  its  body  evaluated  with  the 
formal  parameters  bound  to  the  argument  values.  If  no  region  is  specified 
for  a  formal  parameter,  then  C*  is  assumed,  and  the  body  of  the  subroutine 
must  not  contain  any  assignments  to  that  formal.  If  a  region  is  specified 
for  a  formal,  then  a  new  location  in  that  region  is  allocated  and  given  the 
argument  as  its  value;  the  formal  is  then  bound  to  this  location.  Assignments 
to  such  formals  are  allowed,  provided  the  region  is  not  «■*. 

FX  uses  “call-by-sharing”  semantics  ;  a  set !  on  a  formal  parameter  only 
changes  the  binding  of  the  formal  and  does  not  change  variable  bindings  in 
the  caller’s  environment. 

Type  Information:  If  the  type  of  expm  is  Texphody,  then  the  type  of  the 
subroutine  value  created  is: 

(subr  Eexp  {TexPl  Texp2. . .  Texpn)  Texphody). 

where  Eexp  is  the  latent  effect  of  the  subroutine.  Eexp  is  computed  by 
performing  effect  masking  on  the  maxef  f  of  (alloc  Rexp{ )  and  the  effects  of 
the  exp- . 

Effect  Information:  The  effect  of  a  lambda  expression  is  pure,  i.e.  creat¬ 
ing  a  subroutine  value  is  a  pure  operation.  The  effect  Eexp  will  be  used  in 
determining  the  effect  of  an  application  involving  the  subroutine  value. 
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lambda  (continued) 


value  expression 


Examples: 

; ;  A  nullary  subroutine  which  returns  the  value  of  x 

•  i 

(lambda  ()  x) 

;;  The  "apply-twice"  functional  on  booleans. 

I  • 

(lambda  ((g  (subr  pure  (bool)  bool)) 

(x  bool)) 

(g  (g  x))) 


Application 


value  expression 


(exp  exp1. . .  expn) 

Semantics:  The  expressions  exp  and  expi  are  evaluated  sequentially,  from 
left  to  right.  If  exp  is  polymorphic,  then  implicit  projection  is  used  to  obtain 
a  subroutine  value  (see  page  41).  The  exp{  are  the  actual  parameters,  or 
arguments,  to  the  subroutine.  The  formal  parameters  of  the  subroutine  are 
allocated  and  bound  to  the  argument  values,  and  the  body  of  the  subroutine 
is  then  evaluated  in  the  resulting  environment.  The  value  of  the  application 
expression  is  the  result  of  the  evaluation  of  the  subroutine  body. 

Type  Information:  exp  must  have  type  (subr  Eexp  ( Texpl. . .  Texpn) 
Texpret).  The  number  of  actual  and  formal  parameters  must  be  the  same. 
The  type  of  each  ezp,  must  be  a  subtype  of  Texpi. 

The  type  of  the  application  expression  is  the  return  type,  Texprtl,  of  the 
subroutine. 

Effect  Information:  The  effect  of  the  application  expression  is  computed 
by  performing  effect  masking  on  the  maxett  of  the  latent  effect  of  the  sub¬ 
routine,  Eexp ,  and  the  effects  of  exp  and  the  ezft. 

Examples: 

; ;  A  synonym  for  # f . 

i  • 

(not?  #t) 

; ;  ...  and  another  for  #t. 

t  i 

(and?  #t  (not?  #f)) 


letrec 


value  expression 


(letrec  ((varx  expx  \Rcxpx)). ..)  explb  exp2b. . .) 

The  body  of  the  letrec  expression,  expxb  exp2 b. . . ,  is  treated  as  though 
(begin  explb  exp2b. . .)  is  written. 

The  vati  must  all  be  distinct. 

The  expression  to  which  war,-  is  bound  must  be  either 

•  a  (possibly  polymorphic)  syntactic  subroutine,  i.e.,  a  (possibly  empty) 
nest  of  plambda  forms  followed  by  a  subroutine  form.  If  the  subroutine 
is  recursive,  its  body  must  be  of  the  form  (the  Eexp{  Texp{  ezp,). 

•  a  non-recursive,  non-subroutine  value  expression. 

A  the  expression  is  necessary  since  it  is  not  possible,  in  general,  to  de¬ 
termine  the  types  and  effects  of  arbitrary  recursive  expressions.  The  pro¬ 
grammer  must  supply  them. 

Semantics:  First,  all  of  the  var,-  are  allocated,  each  in  Rexpi  (or  if  un¬ 
specified).  Then,  the  expt  are  successively  evaluated  and  bound  to  the  cor¬ 
responding  ear,  .  This  order  is  important  because  it  allows  any  of  the  expj  to 
refer  to  some  war,- ,  thus  providing  for  mutual  recursion.  This  process  is  sub¬ 
ject  the  following  restriction:  all  variables  that  can  be  recursively  reached,  in 
the  graph  of  variable  usage,  from  an  expression  ezp,-  which  is  not  a  (possibly 
polymorphic)  syntactic  subroutine,  must  be  defined  before  the  processing 
of  the  binding  for  war,-.  Since  evaluation  of  a  (possibly  polymorphic)  syn¬ 
tactic  subroutine  does  not  imply  the  evaluation  of  the  body  of  the  lambda 
expression,  this  restriction  does  not  apply  to  the  bindings  involving  such 
subroutines.  Typically,  the  ezp;-  are  lambda  expressions  and  therefore  no 
problem  exists. 

After  all  the  bindings  are  done,  the  body  of  the  letrec  expression  is 
evaluated  in  the  environment  with  these  additional  bindings. 

A  subroutine  is  tail-recursive  if  all  of  the  values  returned  from  recursive 
cal’3  are  themselves  returned  without  further  computation.  FX  guarantees 
that  a  properly  tail-recursive  subroutine  will  be  translated  to  an  iteration. 
Since  do  loops  can  be  implemented  with  recursive  subroutine  calls  which  the 
compiler  recognizes  as  iterative,  the  FX  kernel  need  not  have  any  separate 
looping  expressions. 

Type  Information:  The  type  of  var,  is  the  type  of  expt.  The  type  of  the 
letrec  expression  is  the  type  of  its  body. 
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letrec  (continued) 


vaiue  expression 


Effect  Information:  The  effect  of  a  letrec  expression  is  computed  by 
performing  effect  masking  on  the  naxef  f  of  (alloc  Rexpt)  and  the  effects  of 
the  expi  and  the  exp^. 

Example: 

;;  The  traditional  factorial  program. 

•  i 

(letrec  ((fact  (laabda  ((x  lnt)) 

(the  pure  int 

(if  (-  x  0)  1 

(*  x  (fact  (-  x  1)))))))) 

(fact  10)) 
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plain  bda 


value  expression 


(plambda  ((rfj  Kexp1). . . )  exp) 

The  di  must  all  be  distinct. 

Semantics:  Just  as  lambda  provides  a  means  of  abstracting  expressions 
over  ordinary  variables,  plambda  provides  a  means  of  abstracting  expressions 
over  description  variables.  The  kind  of  these  variables  must  be  type,  region, 
effect  or  any  dfunc  expression  whose  eventual  kind  is  type. 

The  evaluation  of  plambda  expression  yields  a  polymorphic  value  that 
takes  n  arguments  and,  when  projected  onto  n  descriptions  each  of  the  proper 
kind,  i.e.  argument  <  is  of  kind  Kexp, ,  returns  the  value  of  exp  evaluated 
with  the  formal  parameters  bound  to  the  argument  descriptions.  (See  the 
description  of  the  pro  j  expression  on  page  40  and  the  description  of  implicit 
projection  on  page  41.) 

The  body  of  a  plambda  expression,  exp,  must  be  a  pure  expression. 
Because  of  this  restriction,  the  body  of  a  plambda  expression  can  be  eval¬ 
uated  when  the  plambda  expression  is  evaluated  rather  than  each  time  it 
is  projected.  Every  FX  implementation  guarantees  that  projection  has  no 
run-time  cost. 

Type  Information:  Assuming  that  the  type  of  exp  is  Texp,  the  type  of  a 
polymorphic  value  defined  as  above  is  (poly  ((di  Kexp^). . .)  Texp). 

Effect  Information:  The  effect  of  a  plambda  expression  is  pure. 

Example: 

; ;  The  polymorphic  identity  function. 

»  » 

(plambda  ((t  type)) 

(lambda  ((x  t))  x)) 
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proj 


value  expression 


(proj  exp  Dexpv  . .) 


Semantics:  exp  must  evaluate  to  a  polymorphic  value,  as  generated  by 
plambda.  The  Dexpi  are  the  actual  parameters  (or  arguments)  for  the  pro¬ 
jection.  The  actuals  are  bound  to  the  formal  parameters  specified  in  the 
definition  of  the  polymorphic  value.  The  number  of  actuals  and  the  number 
of  formats  must  be  the  same.  Each  Dexpi  must  be  of  the  kind  specified  for 
the  corresponding  formal  in  the  polymorphic  value’s  definition.  The  body 
of  the  polymorphic  value  is  evaluated  with  the  formal  parameters  replaced 
by  the  actual  parameters. 

There  is  an  important  restriction  on  the  way  a  polymorphic  expression 
may  be  projected  onto  different  arguments  of  kind  region  and  effect:  all 
the  mutable  region  arguments  must  be  mutually  disjoint  and  must  not  in¬ 
tersect  with  free  mutable  region  variables  or  constants  used  inside  the  type 
of  the  body  of  the  polymorphic  expression.  This  rule  is  called  the  region 
anti-aliasing  rule.  (Region  descriptions  which  intersect  are  said  to  alias.) 

Polymorphic  subroutine  values  in  the  operator  position  of  an  application 
expression  may  be  implicitly  projected  in  most  cases.  (See  page  41.) 

Type  Information:  The  type  of  a  projection  of  a  polymorphic  value  of 
type  (poly  ((di  Kexpi)...)  Texp)  is  Texp  with  all  occurrences  of  the  d, 
replaced  by  their  corresponding  actual  parameters. 

Effect  Information:  The  effect  of  a  proj  expression  is  pure. 

Example: 

; ;  Use  the  polymorphic  identity  function  to  get 
; ;  a  boolean  version. 

(proj  (plambda  ((t  type)} 

(lambda  ((x  t))  x)) 

bool) 
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Implicit  Projection 


value  expression 


(exp  expi . . .) 

Semantics:  exp  must  evaluate  to  a  polymorphic  value,  as  generated  by 
plambda.  The  polymorphic  value  is  projected  onto  appropriate  description 
values  to  produce  a  subroutine  value,  which  is  then  applied  to  the  expi.  The 
projection  and  application  are  performed  as  described  in  the  documentation 
for  proj  (page  40)  and  application  (page  36). 

The  description  values  used  as  arguments  to  the  projection  are  chosen  so 
that  the  type  of  each  of  the  expj  are  subtypes  of  the  types  of  the  correspond¬ 
ing  formal  parameters  of  the  resulting  subroutine.  An  implicit  projection 
is  possible  if  the  descriptions  required  as  projection  arguments  are  specified 
completely  by  the  types  of  the  actual  parameters.  If  the  types  of  the  for¬ 
mal  parameters  do  not  utilize  the  maxeff  or  runion  constructors,  then  the 
requisite  projection  arguments  are  specified  completely,  and  will  be  used. 

Projection  arguments  of  kind  region  which  are  not  otherwise  implicitly 
specified  by  the  type  of  the  actual  parameters  are  given  the  current  value  of 
the  special  description  variable  default-region.  This  variable  is  initially 
bound  to  the  value  C*,  but  may  be  rebound  by  the  programmer  using  plet 
pletrec,  or  plambda. 

Type  Information:  The  type  of  an  implicit  projection  and  application  of 
a  polymorphic  subroutine  is  the  return  type  of  the  subroutine  with  all  oc¬ 
currences  of  the  description  variables  bound  by  plambda  replaced  by  the 
implicitly  chosen  projection  arguments. 

Effect  Information:  The  effect  of  an  implicit  projection  and  application 
of  a  polymorphic  value  is  computed  by  performing  effect  masking  on  the 
maxeff  of  the  latent  effect  of  the  subroutine  (with  the  d,  replaced  by  the 
implicit  projection  arguments)  and  the  effects  of  exp  and  the  expt. 
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Implicit  Projection  (continued) 


value  expression 


Example: 

; ;  Invoke  the  polymorphic  identity  function  with 
;;  a  boolean  argument,  implicitly  projecting  to  get  a 
; ;  boolean  version. 

((plambda  ((t  type)) 

(lambda  ((x  t))  x)) 

#t) 


(plet  ((rfi  Dexpt). . . )  expt  ex p3. . . ) 


The  body  of  the  plet  expression,  expl  ezp2. . . ,  is  treated  as  though 
(begin  expy  exp3. . .)  is  written. 

The  dk  must  all  be  distinct. 

Semantics:  plet  provides  a  way  of  making  type,  effect,  region  and  descrip¬ 
tion  function  synonyms,  or  shorthand  names,  for  complicated  description 
expressions. 

The  value  of  a  plet  value  expression  is  the  value  of  its  body.  Whenever 
di  is  encountered  in  the  plet  body,  it  is  replaced  by  Dexpi .  A  reference  to 
a  d{  in  Dexpj  is  taken  to  refer  to  a  binding  for  di  in  the  surrounding  (outer) 
scope.  (See  the  description  of  pletrec  for  a  discussion  of  recursive  types.) 

Type  Information:  The  type  of  the  plet  expression  is  the  type  of  its  body 
with  Dexpi  substituted  for  di. 

Effect  Information:  The  effect  of  the  plet  expression  is  the  effect  of  its 
body  with  Dtzpi  substituted  for  di. 

Example: 

; ;  The  Identity  function  on  a  complicated  type . 

•  i 

(plet  ((t  (ref  (subr  pure  (bool)  bool)  61))) 

(lambda  ((a- subroutine  t))  a -subroutine)) 


pletrec 


value  expression 


(pletrec  ((<fi  DexpJ...)  ezp1  exp2. . .) 

The  body  of  the  pletrec  expression,  exp1  exp2. . . ,  is  treated  as  though 
(begin  expl  txp2. . .)  is  written. 

The  di  must  all  be  distinct. 

Semantics:  First,  all  of  the  di  are  read  and  these  names  are  made  available. 
Then,  the  Detpi  are  successively  evaluated  and  bound  to  the  corresponding 
di.  This  order  is  important  because  it  allows  any  of  the  Dexp-  to  refer 
to  some  di,  thus  providing  for  mutual  recursion.  This  process  is  subject 
to  the  following  restriction:  all  description  variables  that  can  be  recursively 
reached,  in  the  graph  of  description  variable  usage,  from  an  expression  Dexp{ 
must  be  defined  before  the  processing  of  the  binding  for  di,  unless  their  kinds 
are  type.  Typically,  the  Dexpj  are  recursive  type  descriptions  and  so  there 
is  no  problem.  An  error  is  signalled  if  any  of  the  di  is  defined  as  itself. 

The  value  of  a  pletrec  special  form  is  its  evaluated  body  with  the  (pos¬ 
sibly  recursive)  definitions  of  the  di  substituted  for  the  di . 

Type  Information:  The  type  of  a  pletrec  value  expression  is  the  type  of 
its  body  with  all  occurrences  of  di  replaced  by  Dezp,. 

Effect  Information:  The  effect  of  a  pletrec  construct  is  the  effect  of  its 
body  with  Dezp,  substituted  for 

Example: 

; ;  A  contrived  example . 

*  i 

(pletrec  ((tl  (subr  pure  (bool)  t2)) 

(t2  (subr  pure  ()  tl))) 

(lambda  ((x  tl)) 

((x  #t))))  # 


44 


m 

m 

m 

u 


$9 

W 


value  expression 


(if  exp0  txP\  exPi) 


Semantics:  The  expression  exp0  must  be  of  type  bool.  If  exp0  evaluates 
to  #t,  then  the  value  of  the  11  expression  is  the  value  of  expl,  otherwise  the 
value  of  the  11  is  the  value  of  ezp3>  The  type  of  one  of  the  arms  of  the  11 
expression  must  be  a  subtype  of  the  other. 


Type  Information:  The  type  of  an  11  expression  is  the  maximum  of  the 
types  of  expi  and  exp3. 


Effect  Information:  The  effect  of  an  11  statement  is  the  maxell  of  the 
effect  of  the  three  expressions  ezp0,  exp1)  and  exp3. 


Examples: 


;;  The  short-circuit  "and". 


(11  x  y  #1) 


; ;  The  "not"  lunction. 


(lambda  (x)  (11  x  #1  #t)) 
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value  expression 


(set)  t/ar  ezp) 


Semantics:  set!  is  the  variable  assignment  operator.  First,  exp  is  evalu¬ 
ated.  Then,  the  resulting  value  is  placed  in  the  location  denoted  by  var  The 
value  of  a  set !  expression  is  #u. 

It  is  a  static  effect  error  for  var  to  be  in  the  region  fi*.  Furthermore,  if 
var  is  of  type  Texp,  then  the  type  of  exp  must  be  a  subtype  of  Texp. 


Type  Information:  The  type  of  the  set!  expression  is  unit. 


Effect  Information:  The  effect  of  an  assignment  expression  is  (write  r), 
where  r  is  the  region  var  is  in. 


Examples: 


; ;  Mutate  the  boolean  variable  x  to  It. 


(set!  x  #t)) 


; ;  Set  a  boolean  flag. 


(set!  flag  (and?  a  b)) 
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2.3.  Value  Expressions 


In  addition  to  the  above  language  constructs,  the  kernel  provides  three 
subroutines  which  may  be  used  with  ref  types.  They  are: 

new  :  (poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (alloc  r)  (t)  (ref  t  r)))) 

get  :  (poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (read  r)  ((ref  t  r))  t))) 

set  :  (poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (write  r)  ((ref  t  r)  t)  unit))) 

new  is  used  to  allocate  a  new  location  in  a  particular  region  and  initialize 
the  location  to  some  value.  ( (proj  new  Cl )  #t)  returns  a  reference  to  a 
newly  allocated  location  of  type  (ref  bool  C I )  which  contains  the  initial 
value  #t. 

get  is  used  to  dereference  a  value  of  ref  type,  i.e.  to  return  the  value 
currently  stored  in  the  location  indicated  by  the  reference  value. 

set  is  used  to  replace  the  value  stored  in  the  location  denoted  by  a  ref 
type  with  a  new  value. 
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Ch.  2.  The  FX  Kernel 


Chapter  3 


The  FX  Standard  Types 


This  chapter  describes  the  standard  types  that  are  provided  by  every  FX 
implementation.  These  types  fill  out  the  framework  introduced  by  the  FX 
Kernel  with  a  set  of  useful  types  and  subroutines.  We  present  the  FX  stan¬ 
dard  types  in  order  of  increasing  complexity. 

For  each  data  type,  we  give  a  brief  overview  of  its  purpose,  the  syntax 
of  literals,  and  a  list  of  the  operations  provided. 

Many  of  the  subroutines  described  in  this  chapter  are  abstracted  over 
multiple  descriptions  (see  for  instance,  the  caar  subroutine  which  is  ab¬ 
stracted  over  one  region  and  three  types).  As  a  general  rule,  region  pa¬ 
rameters  are  abstracted  over  first  in  the  definition  of  a  standard  subroutine, 
followed  by  other  descriptions.  This  currying  of  description  abstraction  al¬ 
lows  a  programmer  to  specify  the  region  for  a  standard  subroutine  with  a 
proj  expression  and  to  omit  the  proj  for  the  other  description  parameters. 
The  other  description  parameters  will  be  computed  by  implicit  projection 
(See  page  41  for  a  description  of  implicit  projection.) 

Standard  subroutines  are  generally  abstracted  over  only  one  region  pa¬ 
rameter.  If  the  values  to  be  operated  upon  are  in  different  regions,  the  user 
has  to  pass  the  runion  of  those  regions  as  the  argument.  If  the  operations 
were  abstracted  over  multiple  regions,  then  the  rule  that  disallows  passing 
the  same  region  as  an  argument  to  two  ref  ’  on  parameters  would  prevent  the 
use  of  the  operation  on  values  in  the  same  region. 

Unless  otherwise  stated,  there  is  no  type  inclusion  within  these  data 
types,  and  literals  are  always  immutable. 


Ch.  3.  The  FX  Standard  Types 


3.1  Void 

The  type  void  is  the  type  of  certain  non-terminating  computations.  For 
example,  it  is  the  return  type  of  the  error  function  which  is  described  in 
Chapter  5. 

Description 

The  void  constant  type  is  the  empty  type,  i.e.  there  are  no  values  of  type 
void;  its  kind  is  type. 

The  type  void  is  a  subtype  of  all  types. 

Literals 

There  are  no  literals  of  type  void. 

Operations 

There  are  no  operations  for  the  type  void. 

This  type  is  rarely  used;  one  contrived  example  of  its  use  is: 

(letrec  ((black-hole  (lambda  () 

(the  pure  void 

(black-hole))))) 

(black-hole)) 

3.2  Unit 

The  unit  constant  data  type  is  the  type  of  computations  that  are  only  used 
to  perform  side-effects.  It  is  already  defined  in  the  FX  Kernel  (cf.  previous 
chapter).  Its  kind  is  type. 

Literals 

There  is  one  value  of  type  unit,  namely  #u. 

Operations 

There  are  no  operations  for  the  type  unit. 

The  type  unit  is  generally  used  as  the  type  of  computations  which  return 
no  useful  information. 
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3.3.  Booleans 


;;  The  variable  loo  is  located  in  region  flbar. 


(let 


((mutate  (the  (subr  (write  Cbar)  ()  unit) 
(lambda  () 

(set I  loo  it))))) 


(mutate)) 


3.3  Booleans 

The  bool  constant  data  type  denotes  the  set  of  immutable  boolean  values. 
It  is  already  defined  in  the  FA- Kernel  (cf.  previous  chapter). 

Literals 

There  are  two  boolean  literals,  namely  #t  (for  the  true  boolean)  and  il  (for 
the  false  boolean). 

Operations 

The  FX  implementation  provides  the  classical  boolean  operators: 

equiv?  (subr  pure  (bool  bool)  bool) 

and?  (subr  pure  (bool  bool)  bool) 

or?  (subr  pure  (bool  bool)  bool) 

not?  (subr  pure  (bool)  bool) 

The  more  classical  and  and  or  special  forms,  which  perform  short-circuit 
evaluations,  are  defined  in  the  next  chapter.  Note  also  that  equiv?,  which 
is  the  equality  function  on  booleans,  could  be  easily  defined  with  the  other 
functions;  equiv?  is  provided  as  a  convenience  to  the  programmer. 


3.4  Integers 

The  int  constant  data  type  denotes  the  set  of  immutable  integers.  The  kind 
of  int  is  type. 

Literals 

The  FX  int  data  type  supports  four  distinct  bases  for  integer  literals.  The 
distinction  is  indicated  by  a  prefix,  namely  #b  (binary),  #o  (octal),  #d  (dec¬ 
imal)  and  #x  (hexadecimal).  If  no  prefix  is  supplied,  #d  is  assumed. 


$ 
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An  integer  literal  is  formed  by  an  optional  prefix,  an  optioned  sign  (♦  is 
assumed  if  omitted),  and  a  non-empty  succession  of  digits  that  are  defined 
in  the  given  base.  The  precision  of  integer  values  is  unspecified. 


Operations 


The  integer  operations  with  their  types  are: 


(subr  pure  (int  int)  bool) 
(subr  pure  (int  int)  bool) 
(subr  pure  (int  int)  bool) 
(subr  pure  (int  int)  bool) 
(subr  pure  (int  int)  bool) 


These  are  the  five  standard  comparison  functions  on  integers. 


(subr  pure  (int  int)  int) 
(subr  pure  (int  int)  int) 
(subr  pure  (int  int)  int) 
(subr  pure  (int  int)  int) 


These  are  the  four  standard  arithmetic  operations  on  integers.  A  dy¬ 
namic  error  is  signalled  in  case  of  division  by  zero  or  overflow. 


remainder 

modulo 

abs 


(subr  pure  (int  int)  int) 
(subr  pure  (int  int)  int) 
(subr  pure  (int)  int) 


The  first  two  functions  implement  number-theoretic  integer  division;  the 
functions  remainder  and  modulo  differ  on  negative  arguments  (remainder 
has  always  the  sign  of  the  dividend).  The  abs  function  erases  the  sign  of  its 
argument. 


3.5  Floating-point  numbers 


The  float  constant  data  type  denotes  the  set  of  immutable  real  numbers. 
The  kind  of  float  is  type. 
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3.5.  Floating-point  numbers 


Literals 


The  FX  float  data  type  supports  the  standard  FORTRAN-inspired  syntax 
for  literals.  These  are  typical  examples  of  floating-point  number  literals: 


+0.66066 

0.66e-l 

-6.66E-1 

0.0 


a  Boat  approximation  of  2/3 
a  less  accurate  one 
its  opposite  value 
the  Boating-point  number  zero 


A  float  literal  is  formed  by  an  optional  sign,  a  non-empty  succession  of 
decimal  digits,  a  decimal  point,  a  non-empty  succesion  of  decimal  digits  and 
an  optional  exponent  denoted  by  the  letter  “E”  or  “e” ,  an  optional  sign  and 
a  sequence  of  decimal  digits.  The  precision  of  floating  point  values  is  un¬ 
specified;  this  means  that  truncation  may  occur  if  the  number  of  significant 
digits  is  too  large. 

Operations 

The  floating-point  operations  with  their  types  are: 

Xl»  :  (subr  pure  (float  float)  bool) 

fl<  :  (subr  pure  (float  float)  bool) 

fl>  :  (subr  pure  (float  float)  bool) 

fl<>:  (subr  pure  (float  float)  bool) 

fl>":  (subr  pure  (float  float)  bool) 

These  are  the  five  standard  comparison  functions  on  floats. 


(subr  pure  (float  float)  float) 
(subr  pure  (float  float)  float) 
(subr  pure  (float  float)  float) 
(subr  pure  (float  float)  float) 


These  are  the  four  standard  arithmetic  operations  on  floats.  A  dynamic 
error  is  signalled  in  case  of  division  by  zero,  overflow  or  underflow. 

flabs  :  (subr  pure  (float)  float) 


This  function  erases  the  sign  of  its  argument. 
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exp  : 
log  : 
sin  : 
cos  : 
tan  : 
asin: 
acos: 
at  an  : 
sqrt: 


(snbr  pure 
(subr  pure 
(subr  pure 
(subr  pure 
(subr  pure 
(subr  pure 
(subr  pure 
(subr  pure 
(subr  pure 


(float)  float) 
(float)  float) 
(float)  float) 
(float)  float) 
(float)  float) 
(float)  float) 
(float)  float) 
(float)  float) 
(float)  float) 


These  are  the  basic  arithmetic  operations  on  floats. 


floor 

ceiling 

truncate 

round 


(subr  pure  (float)  int) 
(subr  pure  (float)  int) 
(subr  pure  (float)  int) 
(subr  pure  (float)  int) 


int->float:  (subr  pure  (int)  float) 


We  provide  the  classical  conversion  functions  from  integers  to  floats,  and 
vice-versa. 


3.6  Characters 

The  char  constant  type  denotes  the  set  of  immutable  characters.  The  kind 
of  char  is  type. 

Literals 

Character  literals  are  represented  with  the  #\character  or  #\identiGer  nota¬ 
tion  and  must  be  followed  by  a  delimiter.  For  instance,  #\a  is  the  lower  case 
“a”  character,  while  #\Z  is  the  upper  case  letter  “z”;  #\newline  denotes  the 
NewLine  character. 

The  list  of  allowed  identifiers  must  include: 

backspace  newline  page 
space  tab 

The  case  used  in  the  character  identifiers  is  irrelevant;  #\newline  is 
equivalent  to  #\NewLine  for  example. 
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3.6.  Characters 


Operations 

The  operations  on  characters  are  either  case  sensitive  or  case  insensitive. 
The  latter  option  is  indicated  by  a  -ci  suffix  in  the  operation  name. 

There  is  a  total  ordering  on  characters,  which  is  compatible  with  the 
ASCII  standard  on  lower-case  letters,  upper-case  letters  and  digits  (without 
any  interleaving  between  letters  and  digits). 

The  operations  defined  on  characters  with  their  types  are: 

char-?  (subr  pure  (char  char)  bool) 

char<?  (subr  pure  (char  char)  bool) 

char>?  (subr  pure  (char  char)  bool) 

char<*?  :  (subr  pure  (char  char)  bool) 

char>-?  :  (subr  pure  (char  char)  bool) 

These  are  the  five  boolean  comparison  functions  on  characters. 

char-ci-?  (subr  pure  (char  char)  bool) 

char-ci<?  (subr  pure  (char  char)  bool) 

char-ci>?  (subr  pure  (char  char)  bool) 

char-ci<-?  :  (subr  pure  (char  char)  bool) 

char-ci>»?  :  (subr  pure  (char  char)  bool) 

These  five  comparison  functions  treat  upper-  and  lower-characters  as  the 
same. 

char-alphabetic?  (subr  pure  (char)  bool) 

char-numeric?  (subr  pure  (char)  bool) 

char-whitespace?  (subr  pure  (char)  bool) 

A  character  is  alphabetic  if  its  lower-case  equivalent  is  between  #\a  and 
#\z.  It  is  numeric  if  it  is  between  #\0  and  #\9. 

char-lower-case?  (subr  pure  (char)  bool) 

char-upper-case?  (subr  pure  (char)  bool) 

char-upcase  (subr  pure  (char)  char) 

char-downcase  (subr  pure  (char)  char) 

The  two  boolean-valued  subroutines  test  the  case  of  a  character.  The  two 
last  subroutines  map  a  character  to  the  corresponding  case;  non-alphabetic 
characters  remain  unchanged. 
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char->int  :  (subr  pure  (char)  int) 
int->char  :  (subr  pure  (int)  char) 

These  two  subroutines  convert  between  characters  and  their  positions  in 
the  ordering  mentioned  above. 


3.7  Strings 

The  string  type  constructor  is  used  to  denote  the  set  of  zero-indexed  se¬ 
quences  of  characters.  Once  created,  a  string  is  of  constant  length. 

Description 

The  type  of  a  string  located  in  a  region  Rexp  is: 

(string  Rexp)  ::  type 
and  the  kind  of  string  is: 

string  ::  (dfunc  (region)  type) 

A  type  (string  Rexpx)  is  a  subtype  of  (string  Rexp2)  iff  Rexp1  is  a  subregion 
of  Rexp2. 

Literals 

A  string  literal  is  represented  by  a  double-quote  ("),  a  sequence  of  characters 
(where  \  is  the  escape  character  for  itself  and  the  double-quote  character), 
and  an  ending  double-quote. 

Operations 

The  operations  on  strings  with  their  types  are: 

make- string  (poly  ((r  region)) 

(subr  (alloc  r) 

(int  char)  (string  r))) 
string- length  :  (poly  ((r  region)) 

(subr  pure  ((string  r))  int)) 
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string-fill I 


3. 7.  Stnaga 


The  make -string  function  creates  a  string  in  the  region  r  of  the  length 
given  by  the  first  argument  and  fills  it  with  the  second  argument.  The 
latent  effect  of  string-length  is  pure  since  the  length  of  a  string,  which  is 
constant,  can  be  obtained  without  looking  at  (i.e.  have  a  read  effect  on)  the 
string  value. 

string-ref  :  (poly  ((r  region)) 

(subr  (read  r) 

((string  r)  int)  char)) 
string-set  1  (poly  ((r  region)) 

(subr  (write  r) 

((string  r)  int  char)  unit)) 
string-fill I  (poly  ((r  region)) 

(subr  (write  r) 

((string  r)  char)  unit)) 

substring-fill! 

(poly  ((r  region)) 

(subr  (write  r) 

((string  r)  int  int  char)  unit)) 

The  function  string-ref  returns  the  n-th  character  in  a  string  where  n 
is  the  second  argument.  The  subroutine  string- set !  modifies  its  argument 
at  the  given  index.  The  subroutine  string-fill!  fills  its  argument  with 
the  given  character.  The  last  subroutine  (substring-fill!)  allows  one  to 
fill  a  part  of  a  string  by  the  character  given  as  the  last  argument;  the  first 
int  gives  the  beginning  index  and  the  second  is  one  greater  than  the  index 
of  the  last  position  in  the  substring.  It  is  a  dynamic  error  to  try  to  access 
out-of-bounds  elements  of  strings.  The  mutating  subroutines  return  #u. 

string*? , 
string<? . 
string>? , 

8tring<*?, 
string>*? , 
string-ci*? , 
string-ci<?, 

Btring-ci>? , 
string-ci<“? , 
string-ci>*? 

(poly  ((r  region)) 
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(sabr  (read  r) 

((string  r)  (string  r))  bool)) 

These  are  the  lexicographic  comparison  functions  on  strings;  the  case- 
insensitive  ones  have  a  -ci  suffix. 

substring  : 

(poly  ((rl  region)) 

(subr  (read  rl) 

((string  rl)  int  int) 

(poly  ((r2  region)) 

(subr  (alloc  r2)  ()  (string  r2))))) 

string-append  : 

(poly  ((rl  region)) 

(subr  (read  rl) 

((string  rl)  (string  rl)) 

(poly  ((r2  region)) 

(subr  (alloc  r2)  ()  (string  r2))))) 

string-copy  : 

(poly  ((rl  region)) 

(subr  (read  rl) 

((string  rl)) 

(poly  ((r2  region)) 

(subr  (alloc  r2)  0  (string  r2))))) 

These  functions  create  newly  allocated  strings  from  their  argument(s). 
The  substring  arguments  must  specify  valid  index  ranges.  More  pre¬ 
cisely,  it  is  a  dynamic  error  if  the  first  integer  argument  (which  is  the  index 
into  the  string  argument  s,  located  in  r,  of  the  first  character  to  be  included 
in  the  substring)  is  not  between  zero  and  the  length  of  the  string  minus  one, 
inclusive,  if  the  second  integer  argument  (which  is  one  larger  than  the  index 
into  s  of  the  last  character  to  be  included  in  the  substring)  is  not  between 
zero  and  the  length  of  the  string,  inclusive,  and  if  the  first  integer  argument 
is  not  less  than  or  equal  to  the  second.  If  the  two  integer  arguments  are 
equal,  then  the  substring  returned  is  the  empty  string  (""). 

For  example,  consider 

((proj  ((pro]  substring  Qfrom)  s  start  end)  Cto)) 

start  is  the  index  in  the  string  s  of  the  first  character  of  the  result;  it  should 
be  less  than  or  equal  to  end  which  is  the  last  (non-included)  character  index 


3.8.  Symbols 


* 


in  a.  The  following  table  shows  some  sample  results  for  different  values  of 
s ,  start ,  and  end: 


s 

start 

end 

result 

"boondoggle" 

4 

7 

"dog" 

"foobar" 

3 

3 

tl  It 

"insipid" 

4 

7 

"pid" 

"yuk" 

0 

1 

Mytt 

The  string-append  function  implements  the  concatenation  of  its  argu¬ 
ments. 

string -copy  yields  a  fresh  copy  of  its  argument. 


3.8  Symbols 

The  symbol  constant  data  type  is  used  to  denote  the  set  of  immutable  values 
whose  name  is  the  only  important  characteristic.  Its  kind  is  type. 

Literals 

A  symbol  literal  is  represented  with  the  quote  special  form. 


VI' 

5.1 
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value  expression 


(quote  td) 


id  is  any  identifier  (see  the  Conventions  section). 
’id  is  equivalent  to  (quote  id). 


Semantics:  A  quoted  identifier  evaluates  to  the  symbol  whose  name  is  the 
upper-case  equivalent  of  the  identifier. 


Type  Information:  (quote  id)  is  of  type  syabol. 


Effect  Information:  A  quote  expression  is  pure. 


Example: 


; ;  The  following  expression  returns  tft . 


(symbol*?  (quote  Foo)  *f0o) 


3.9.  References 

Operations 

We  provide  conversion  functions  on  symbols  to  and  from  strings: 

symbol->string  : 

(poly  ((r  region)) 

(subr  (alloc  r)  (symbol)  (string  r))) 
string- >symbol  : 

(poly  ((r  region)) 

(subr  (read  r)  ((string  r))  symbol)) 

However,  the  most  important  characteristic  of  symbols  is  that  they  are 
treated  in  a  very  special  way  by  the  FX  interpreter  or  compiler;  they  are 
interned.  For  instance,  if  the  symbol  ’foo  is  used  in  two  different  places  in 
a  program,  they  will  in  fact  refer  to  the  same  (physical)  value.  To  detect 
whether  two  symbol  values  are  the  same  in  this  very  precise  sense,  we  pro¬ 
vide  the  symbol*?  function  which  tests  for  the  physical  equality  (i.e.,  the 
identity)  of  two  symbols: 

symbol"?  (subr  pure  (symbol  symbol)  bool) 

The  hash  function  computes  a  hash  code  from  its  argument, 
hash  :  (subr  pure  (symbol)  int) 

3.9  References 

The  ref  type  constructor  is  used  to  denote  the  set  of  values  that  are  refer¬ 
ences  to  other  values.  It  is  already  defined  in  the  FX  Kernel  (cf.  previous 
chapter). 

Description 

The  type  of  a  reference,  located  in  a  region  Rexp,  to  a  value  of  type  Texp  is: 

(ref  Texp  Rexp)  ::  type 

and  the  kind  of  ref  is: 

ref  ::  (dfunc  (type  region)  type) 

A  type  (ref  Texpx  Rexpx)  is  a  subtype  of  (ref  Texp2  Rexp2)  iff  Rexpx  is  a 
subregion  of  Rexp2  and  Texpx  is  interconvertible  to  Texp2)  or  Rexpx  =  Rexp2 
=  C*  and  Texpx  is  a  subtype  of  Texp2. 
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Literals 

There  are  no  literals  for  ret  values. 

Operations 

There  are  three  operations  on  reference  values,  which  have  already  been 
introduced  in  the  Chapter  2. 

new  :  (poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (alloc  r)  (t)  (ret  t  r)))) 
get  :  (poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (read  r)  ((ref  t  r))  t))) 
set  :  (poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (write  r)  ((ref  t  r))  unit))) 

It  is  a  static  effect  error  to  apply  set  to  a  ref  value  in  the  region  C-. 

3.10  Uniqueofs 

The  uniqueof  type  constructor  is  used  to  denote  sets  of  values  in  which  each 
element  is  distinguishable. 

Description 

The  type  of  a  unique  value  of  type  Tezp  is 

(uniqueof  Tezp)  •  e  type 
and  the  kind  of  uniqueof  is: 

uniqueof  ::  (dfunc  (type)  type) 

A  type  (uniqueof  Tezpi)  is  a  subtype  of  (uniqueof  Texp^)  iff  Tezpl  is  a 
subtype  of  Tezp} . 


Literals 

There  are  no  literals  for  uniqueof  values. 


3.11.  Pairs 
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Operations 

There  are  three  operations  on  uniqueof  values: 

unique  :  (poly  ( (t  type)) 

(subr  (alloc  Cuniqueof)  (t)  (uniqueof  t))) 

The  unique  subroutine  creates  a  unique  value  from  a  value  of  type  t. 
The  alloc  effect  on  Cuniqueof  is  used  to  ensure  that  no  memoization  will 
be  performed  on  calls  to  unique. 

value  :  (poly  ((t  type)) 

(subr  pure  (uniqueof  t)  t)) 

The  value  subroutine  returns  the  embedded  value  corresponding  to  a 
unique  value. 

eq?  (poly  ((tl  type)  (t2  type)) 

(subr  pure  ((uniqueof  tl)  (uniqueof  t2))  bool)) 

The  boolean-valued  subroutine  eq?  tests  whether  two  unique  values  were 
created  by  the  same  call  to  the  unique  function. 


w. 


3.11  Pairs 

The  notion  of  pair  in  FX  is  the  same  as  the  standard  Lisp  one. 

Description 

The  type  of  a  pair,  located  in  a  region  Rexp,  whose  first  element  (CAR)  is 
of  type  Texpl  and  its  second  (CDR)  is  of  type  Texp2  is 

(pairof  T.  xpx  Texp2  Rexp )  ::  type 

and  the  kind  of  pairof  is: 

pairof  ::  (dfunc  (type  type  region)  type) 

A  type  (pairof  Texpn  Texpl2  Rexp{)  is  a  subtype  of  (pairof  Texp2l 
Texp22  Rexp2)  iff  Rexpt  is  a  subregion  of  Rexp2 ,  Texpn  is  interconvertible 
to  Texp2l  and  Texpl2  is  interconvertible  to  Texp22)  or  Rexp j  =  Rexp2  = 
Texpn  is  a  subtype  of  Texp2l  and  Texp12  is  a  subtype  of  Texp22. 
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Literals 

There  are  no  literals  for  pair  values. 

Operations 

We  provide  the  standard  set  of  operations  on  pairs. 

null?  (poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)) 

(subr  pure  ((pairoi  tl  t2  r))  bool))) 

The  function  null?  tests  whether  a  pair  is  actually  null  j.e.  whether  it 
is  equal  to  ()  (see  the  next  section  for  a  description  of  the  null  type). 

cons  : 

(poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)) 

(subr  (alloc  r)  (tl  t2)  (pairoi  tl  t2  r)))) 

car  : 

(poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)) 

(subr  (read  r)  ((pairoi  tl  t2  r))  tl))) 

cdr  : 

(poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)) 

(subr  (read  r)  ((pairoi  tl  t2  r))  t2))) 

caar  : 

(poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)  (t3  type)) 

(subr  (read  r) 

((pairoi  (pairoi  tl  t2  r)  t3  r))  tl))) 

cadar  : 

(poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)  (t3  type)  (t4  type)) 

(subr  (read  r) 

((pairoi  (pairoi  tl 

(pairoi  t2  t3  r) 
r) 
t4 
r)) 
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t2))) 

idem,  con  vari&tione 


The  standard  CONS,  CAR,  CDR  and  C{A|D}+R  operations  are  defined 
in  FX  (up  to  four  A’s  or  D’s  in  C. . .  R).  We  did  not  give  the  types  of  all  the 
C. .  .R  constructs  since  they  are  all  similar. 


set-car! 


(poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)) 

(subr  (write  r)  ((p&irof  tl  t2  r)  tl)  unit))) 

set-cdr! 

(poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)) 

(subr  (write  r)  ((pairol  tl  t2  r)  t2)  unit))) 


These  are  the  standard  Lisp  forms  for  mutation  of  pairs.  These  subrou¬ 
tines  cannot  be  used  with  pairs  of  pairs  that  span  more  them  one  region.  The 
subtyping  rule  for  pairs  does  not  allow  the  programmer  to  pass  a  pair  to  the 
subroutine  if  the  pair  is  not  in  the  precise  region  expected.  The  programmer 
may  supply  his  own  subroutines  to  handle  such  complicated  structures. 


3.12  Null 


The  null  data  type  is  provided  as  the  type  of  the  list  with  r.o  elements. 


Description 


The  kind  of  null  is  type. 

The  type  null  is  a  subtype  of  every  type  of  the  form  (pairof  Texpx 
Texp2  Rexp).  This  subtyping  rule  is  safe  since  there  is  no  mutable  value  of 
type  null. 


Literals 


The  only  value  of  type  null  is  the  literal  (). 


Operations 


There  are  no  operations  which  explicitly  use  null  as  the  type  of  an  argument 
or  as  the  type  of  a  returned  value. 
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Since  null  is  a  subtype  of  any  pair  type,  some  operations  on  pairs  may 
be  applied  to  ( ) .  It  is  a  dynamic  error  to  apply  pair  access  operations  such 
as  car  or  cdr  on  ().  A  dynamic  error  is  signalled  if  set~car!  or  set-cdr! 
is  applied  to  (  ) . 

3.13  Lists 

The  type  constructor  listof  is  used  to  denote  the  set  of  homogeneous  lists 
of  a  given  type,  allocated  in  a  given  region. 

Description 

We  define  listof  in  terms  of  pairof : 

(dlambda  ((t  type)  (r  region)) 

(dletrec  ( (listof -t-in-r  (pairof  t  listof -t-in-r  r))) 
listof-t-in-r)) 

The  type  of  a  list  defined  in  the  region  Rexp  with  elements  of  type  Texp 
is  then: 


(listof  Texp  Rexp)  ::  type 

and  the  kind  of  listof  is: 

listof  ::  (dfunc  (type  region)  type) 

The  seemingly  infinite  recursive  definition  of  listof  does  not  prevent  us 
from  producing  values  of  type  listof  since  null  is  a  subtype  of  any  (pairof 
Texpi  Texp2  Rexp)  and,  then,  of  any  (listof  Texp  Rexp).  Therefore,  ()  is 
the  terminator  of  every  list.  Moreover,  ()  is  used  to  represent  the  empty 
list. 

Literals 

There  are  no  list  literals  for  list  values,  other  than  (). 

Operations 

We  provide  the  classical  operations  on  lists.  Remember  that  the  operations 
defined  for  pairs  apply  equally  here.  In  particular,  use  the  null?  subroutine 
to  determine  if  a  list  is  empty. 


3.13.  Lists 


V7y. 


i? 


list  :  (poly  ((r  region)) 

(poly  ((t  type)) 

(vsnbr  (alloc  r)  t  (listof  t  r)))) 

This  function  takes  a  variable  number  of  arguments  of  type  t;  its  type  is 
built  with  the  vsubr  type  constructor,  which  is  defined  in  the  next  section. 


length  :  (poly  ((r  region)) 
(poly  ((t  type)) 

(subr  (read  r) 


((listof  t  r))  int))) 


The  length  of  a  list  may  be  changed  by  the  program  by  using  set -c  dr ! . 
length  has  a  read  effect  because  it  has  to  take  the  cdr  of  each  pair  of  the 
list  until  it  gets  to  the  end. 

append  :  (poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (maxeff  (read  r)  (alloc  r)) 

((listof  t  r)  (listof  t  r)) 

(listof  t  r)))) 

reverse  :  (poly  ((rl  region)) 

(poly  ((t  type)) 

(subr  (read  rl) 

((listof  t  rl)) 

(poly  ((r2  region)) 

(subr  (alloc  r2) 

()  (listof  t  r2)))))) 

list-tail  :  (poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (read  r) 

((listof  t  r)  int)  (listof  t  r)))) 
list-ref  :  (poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (read  r) 

((listof  t  r)  int)  t))) 

The  function  call  (list-tail  1  k)  returns  the  sublist  of  1  after  omit¬ 
ting  the  first  k  elements.  The  function  call  (list-ref  1  k)  yields  the  k-th 
element  of  the  list  1  (the  first  element  being  the  zero-th). 


meraq  : 
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(poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (read  r) 

((uniqueof  t)  (listof  (uniqueof  t)  r)) 

(listof  (uniqueof  t)  r)))) 

assq  : 

(poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)) 

(subr  (read  r) 

((uniqueof  tl) 

(listof  (pairof  (uniqueof  tl)  t2  r)  r)) 

(pairof  (uniqueof  tl)  t2  r)))) 

Since  the  memq  and  assq  functions  traditionally  use  the  eq?  predicate, 
they  cannot  be  abstracted  over  any  sort  of  FX  types,  but  are  limited  to 
uniqueofs.  Note  that,  contrary  to  Scheme,  these  functions  return  ()  when¬ 
ever  the  uniqueof  argument  does  not  match  any  element  of  the  list  passed 
as  a  second  argument. 

■ember  : 

(poly  ((r  region)) 

(poly  ((t  type)  (e  effect)) 

(subr  (maxeff  (read  r)  e) 

((subr  e  (t  t)  bool) 
t 

(listof  t  r)) 

(listof  t  r)))) 

assoc  : 

(poly  ((rl  region)) 

(poly  ((tl  type)  (t2  type)  (e  effect)) 

(subr  (maxeff  (read  r)  e) 

((subr  e  (tl  t2)  bool) 
tl 

(listof  (pairof  tl  t2  r)  r)) 

(pairof  tl  t2  r)))) 


Contrary  to  the  Lisp  usage,  the  member  and  assoc  functions  have  to  be 
provided  with  a  comparison  predicate  (there  is  no  way  to  provide  in  FX  a 
well-typed  function  equivalent  to  the  general  Lisp  equal?  predicate). 


mmm 


string->li8t  : 

(poly  ((r  region)) 

(subr  (maxeff  (read  r)  (alloc  r)) 

((string  r))  (listof  r  char))) 

list->string  : 

(poly  ((r  region)) 

(snbr  (maxeff  (read  r)  (alloc  r)) 

((llstof  r  char))  (string  r))) 

These  functions  enable  the  conversion  of  lists  of  characters  to  and  from 
strings. 

The  fairly  standard  control  structures  provided  by  Lisp  on  lists  are  fully 
provided  in  the  FX  implementation. 


nap  : 

(poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)  (e  effect)) 

(subr  (maxeff  e  (read  r)  (alloc  r)) 

((subr  e  (tl)  t2)  (listof  tl  r)) 

(llstof  t2  r)))) 

for-each  : 

(poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)  (e  effect)) 

(subr  (maxeff  e  (read  r)) 

((subr  e  (tl)  t2)  (listof  tl  r)) 
unit))) 

reduce  : 

(poly  ((r  region)) 

(poly  ((t  type)  (e  effect)) 

(subr  (maxeff  e  (read  r)) 

((subr  e  (t  t)  t)  (listof  t  r)  t) 
t))) 

where  the  functions  map  and  for-each  are  performed  from  left  to  right  and 
where  the  reduction  done  by  reduce  is  right-associative,  e.g .: 


(reduce  +  (list  1  2  3)  0)  -  (+  1  (+  2  (+  3  0))) 
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3.14  Vsubrs 

MACLISP  “lexprs”  and  CommonLISP  frrest  arguments  are  well-known 
techniques  to  allow  the  definition  of  subroutines  which  accept  a  variable 
number  of  arguments.  This  feature  is  provided  in  FX  with  the  type  con¬ 
structor  vsubr  (for  “variable-subr”). 

Description 

The  type  of  a  subroutine  that  accepts  a  variable  number  of  arguments  of 
type  Texp  (a  list  of  which  is  bound  to  the  sole  formal  parameter) ,  returns  a 
value  of  type  Texprtn,  and  has  a  latent  effect  Eexp  is: 

(vsubr  Eexp  Texp  Texprtn )  ::  type 

The  kind  of  vsubr  is 

vsubr  ::  (dfunc  (effect  type  type)  type) 

A  function  of  type  (vsubr  Eexpl  Texpi  Texprtnl)  is  a  subtype  of  (vsubr 
Eexp2  Texp2  Texprtn2)  iff  Eexpx  is  a  subeffect  of  Eexp2 ,  Texp2  is  a  subtype 
of  Texpx  and  Texprtnl  is  a  subtype  of  Texprtn2. 

Literals 

There  are  no  literals  for  vsubr  values. 

Operations 

apply  : 

(poly  ((r  region)) 

(poly  ((tl  type)  (t2  type)  (e  effect)) 

(subr  (maxeff  e  (read  r)) 

((vsubr  e  tl  t2) 

(listof  tl  r)) 
t2))) 

There  is  one  special  form  to  build  vsubr  expressions,  namely  vlambda, 
and  one  to  use  them,  namely  Variable-length  Application. 


TO 
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v lambda 


value  expression 


(vlambda  ( var  Texp  [Rexp])  exp1  exp2  . . .  expm) 

Semantics:  See  page  34  for  the  detailed  semantics  of  the  basic  lambda 
construct  (i.e.,  without  the  special  binding). 

The  subroutine  takes  zero  or  more  arguments,  each  of  which  must  have 
a  type  compatible  with  Texp.  When  the  function  is  applied  to  these  n 
arguments,  they  are  gathered  in  a  list  of  type  (llstof  Texp  C«);  this  list  is 
then  bound  to  var  allocated  in  the  region  Rexp  (which  defaults  to  6-). 

Type  Information:  If  the  type  of  the  body  of  the  vlambda  is  Texpbody, 
then  the  type  of  the  subroutine  value  created  is: 

(vaubr  Eezp  Texp  Texpiody) 

where  Eexp  is  the  latent  effect  of  the  subroutine.  Eexp  is  computed  by 
performing  effect  masking  on  the  maxef  t  of  (alloc  Rexp)  and  the  effect  of 
the  expt. 

Effect  Information:  The  effect  of  a  vlambda  expression  is  pure. 
Example: 

;;  A  pre-pro jected  (on  €■)  Implementation  of  Hat. 

»  * 

(plambda  C(t  type)) 

(vlambda  (1  t) 

D) 


Variable-length  Application 


value  expression 


(exp  expx  ...) 


Semantics:  The  expression  exp  must  evaluate  to  a  vsubr  value.  The  expi 
are  the  actual  parameters,  or  arguments  to  the  subroutine.  The  expressions 
are  all  evaluated  from  left  to  right  (exp  first).  The  evaluated  arguments  are 
gathered  into  a  list  (allocated  in  ®-).  Then,  the  list  is  bound  to  the  variable 
which  is  the  formal  parameter  specified  in  the  definition  of  the  vsubr  value. 

The  body  of  the  subroutine  is  then  evaluated  with  the  formal  so  bound. 
The  value  of  the  variable-length  application  form  ia  the  value  obtained  by 
thus  evaluating  the  subroutine  body. 

Type  Information:  Each  of  the  expt  must  have  a  subtype  of  the  type  given 
with  the  corresponding  formal  parameter;  if  exp  evaluates  to  a  subroutine 
value  of  type  (vsubr  Eexp  Texp  Texphody)i  then  exp,  must  have  a  subtype  of 
type  Texp. 

The  type  of  the  application  expression  is  the  return  type,  Texphody,  of 
the  subroutine. 

Effect  Information:  The  effect  of  the  application  expression  is  computed 
by  performing  effect  masking  on  the  aaxefl  of  the  latent  effect  of  the  sub¬ 
routine  and  the  effects  of  exp  and  the  exp,-. 


Example: 


;  Vlambda  as  a  list 

•  l 

((vlanbda  (1  int)  1) 


constructor. 
1  2  3  4) 
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I 
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3.15.  Promises 


3.15  Promises 

The  promise  data  type  is  used  to  describe  delayed  values  in  the  sense  of 
Scheme.  A  delayed  value  denotes  the  “promise”  of  a  future  evaluation  of 
a  given  expression;  the  precise  moment  when  this  suspended  expression  is 
evaluated  is  controlled  by  the  user.  This  type  constructor  and  its  operations 
can  be  used  to  create  potentially  infinite  data  structures. 

Description 

The  type  of  a  delayed  value  is: 

(promise  Eexp  Texp)  ::  type 

where  Eexp  is  the  effect  of  evaluating  the  delayed  expression  and  Texp  is  the 
type  of  the  delayed  expression.  The  kind  of  promise  is: 

promise  ::  (dfunc  (effect  type)  type) 

A  promise  value  of  type  (promise  Eexpl  Texp i)  is  a  subtype  of  (promise 
Eexp2  Texp2)  iff  Eexpv  is  a  subeffect  of  Eexp2  and  Texpx  is  a  subtype  of 
Texp2. 


Literals 

There  are  no  literals  for  promise  values. 

Operations 

There  is  only  one  special  form  and  one  subroutine  that  deal  with  promise 
expressions:  delay  creates  a  delayed  expression  and  force  evaluates  its 
argument  and  returns  the  resulting  value. 


i 

i 

l 


» 

* 


t 


delay 


value  expression 


(delay  exp) 

Semantics:  This  special  form  creates  a  delayed  value  from  its  (unevaluated) 
argument.  The  result  of  the  delay  expression  is  the  newly  allocated  delayed 
value. 

Type  Information:  The  type  of  the  delay  expression  is  constructed  with 
the  type  and  (latent)  effect,  Texp  and  Eexp,  of  exp: 

(promise  Eexp  Texp) 

Effect  Information:  If  the  effect  of  exp  is  pure,  then  the  effect  of  (delay 
exp)  is  also  pure.  Otherwise,  the  delay  expression  has  effect  (alloc  Cpromise) . 

Example: 

; ;  A  generator  of  streams 
•  • 

(pletrec  ((int-stream  (patrol  int 

(promise  (alloc  (runion  Cs  Cpromise)) 
lnt-stream) 

Cs») 

(letrec  ((next  (lambda  ((n  int)) 

(the  (alloc  (runion  Cs  Cpromise))  int-stream 
((pro]  cons  Cs) 
n 

(delay  (next  (♦  n  1)))))))) 

(next  0))) 
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The  force  subroutine,  which  evaluates  a  delayed  expression,  has  type: 
force: 

(poly  ((e  effect)  (t  type)) 

(aubr  e  ((promise  e  t))  t)) 

Note  that  forced  expressions  are  memoized;  forcing  a  delayed  value  twice 
is  equivalent  to  a  single  force  operation. 

3.16  Vectors 

The  notion  of  integer-indexed,  homogeneous  data  structure  is  provided  in 
FX  by  the  vectorof  type.  In  FX,  vectors  (sometimes  called  arrays  in  other 
languages)  are  indexed  starting  at  zero  and,  once  created,  are  of  constant 
length. 

Description 

A  vector,  which  is  located  in  a  region  Rexp  and  contains  elements  of  type 
Texp,  has  type: 

(vectorof  Texp  Rexp)  ::  type 

The  kind  of  vectorof  is: 

vectorof  ::  (dfunc  (type  region)  type) 

A  type  (vectorof  Texpl  Rexpx)  is  a  subtype  of  (vectorof  Texp2  Rexp2) 
iff  Rexpx  is  a  subregion  of  Rexp2  and  Texpx  is  interconvertible  to  Texp2,  or 
Rexp i  =  Rexp2  —  C*  and  Texpx  is  a  subtype  of  Texp2. 

Literals 

There  are  no  literals  for  vector  values. 

Operations 

The  allowed  operations  on  vectors  are  given  below: 

make -vector  : 

(poly  ((r  region)) 

(poly  ((t  type)) 
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(subr  (alloc  r)  (int  t)  (vectorof  t  r)))) 

vector  : 

(poly  ((r  region)) 

(poly  ((t  type)) 

(vsubr  (alloc  r)  t  (vectorof  t  r)))) 
vector- length  : 

(poly  ((r  region)) 

(poly  ((t  type)) 

(subr  pure  ((vectorof  t  r))  int))) 
vector-ref  : 

(poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (read  r)  ((vectorof  t  r)  int)  t))) 

The  make -vector  function  creates  a  new  vector  the  number  of  elements 
of  which  is  given  by  its  first  argument  and  the  initial  content  by  the  second. 
The  vector  function  takes  a  variable  number  of  arguments  and  creates  a 
new  vector  with  them  as  initial  values. 

The  latent  effect  of  vector-length  is  pure  since  the  length  of  a  vector, 
which  is  constant,  can  be  obtained  without  looking  at  (i.e.  have  a  read  effect 
on)  the  vector  value. 

The  vector-ref  function  yields  the  value  associated  with  an  index  in  a 
vector;  it  is  a  dynamic  error  if  the  index  is  not  valid,  i.e.  between  zero  and 
the  length  of  the  vector  minus  one  inclusive. 

vector-set! 

(poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (write  r) 

((vectorof  t  r)  int  t)  unit))) 

vector-fill! 

(poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (write  r) 

((vectorof  t  r)  t)  unit))) 

The  vector-set!  function  modifies  its  vector  argument  by  setting  the 
value  of  the  third  argument  at  the  given  index  (second  argument)  .  The 
vector-fill!  function  mutates  its  vector  argument  by  filling  it  with  the 
second  argument.  These  two  functions  return  #u. 


76 


3. 1 7.  Records 


vector->list  : 

(poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (maxeff  (read  r)  (alloc  r)) 

((vectorof  t  r))  (listof  t  r)))) 

liat->vector  : 

(poly  ((r  region)) 

(poly  ((t  type)) 

(subr  (maxeff  (read  r)  (alloc  r)) 

((listof  t  r))  (vectorof  t  r)))) 

These  functions  convert  vectors  to  and  from  lists. 

3.17  Records 

The  notion  of  heterogeneous  data  structures  with  named  fields  is  intro¬ 
duced  in  the  FX  language  via  the  recordof  type  constructor.  There  are 
three  special  forms  for  manipulating  recordof  values:  record,  select  and 
record-set!. 


VvvVC 


I 

y 


recordof 


type  expression 


(recordof  ((fii  Texpx)  . . .  (nm  Tezpm))  Rexp) 

Semantics:  This  is  the  type  of  a  record  (i.e.,  an  ordered  aggregate  data 
structure  containing  zero  or  more  fields)  defined  in  region  Rexp  with  fields 
(ni  Texpj),  . .  ,(nm  Texpm). 

Each  field  has  a  name  (an  identifier)  and  a  type.  The  order  of  the  fields 
within  the  recordof  type  is  relevant  and  the  field  names  must  be  distinct. 

A  record  type  (recordof  ((ni  Tezpn)  . . .  (nm  Texplm))  Rexpl )  is  a  sub- 
type  of  (recordof  ((nj  Texp21)  .  ..(n9  Texp2g))  Rexp2)  iff  Rexp1  is  a  sub- 
region  of  Rcxp2 ,  m  >  q,  and  all  the  Texpu  are  interconvertible  to  Texp2i, 
or 

1.  Rexpx  —  Rexp2  —  C« 

2.  m  >  q 

3.  for  each  field  name  n,-,  Tezpu  is  a  subtype  of  Texp2i 
There  are  no  literals  for  record  values. 

Kind  Information:  The  kind  of  a  recordof  expression  is  type. 

Example: 

; ;  The  type  of  a  person  record. 

■  i 

(recordof  ((nane  (string  C“)) 

(address  (string  •■)) 

(phone -nuaber  (string  •■))) 

•Persons) 
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select 


value  expression 


(select  exp  nk) 

Semantics:  The  select  expression  accesses  a  single  field  of  a  record  value. 
The  first  argument  must  be  an  expression  exp  of  type  (recordof  ((ni  Texpx) 
. .  .(nm  Texpm))  Rexp).  The  field  name  n*  must  be  one  of  the  {n,}.  The 
result  of  the  select  expression  is  the  contents  of  the  nk  field  of  the  record 
value  returned  by  the  evaluation  of  exp. 

Type  Information:  The  type  of  this  expression  is  Texpk. 

Effect  Information:  The  effect  of  this  expression  is  the  maxeff  of  the  read 
effect  on  Rexp  and  the  effect  of  evaluating  exp. 

Example: 

; ;  Taking  the  address  of  Joe  L.  User. 

•  • 

(select  Joe  address) 


re cord- set) 


value  expression 


(record-set!  expx  n  exp2) 

Semantics:  The  record-set!  expression  mutates  a  single  field  of  a  record 
value.  The  first  argument  must  be  an  expression  exp1  of  type  (recordof 
((ni  Texpx)  . . .  (nm  Texpm))  Rexp)  where  the  region  Rexp  is  mutable.  The 
field  name  n  must  be  one  n,  of  the  {ft;}.  The  exp1  is  evaluated  first  and 
then  exp2  is  evaluated  to  yield  a  value  v.  The  field  n,-  of  the  record  expl  is 
then  accordingly  mutated  to  the  new  value  v.  The  value  returned  by  the 
record-set!  expression  is  #u. 

Type  Information:  The  type  of  exp2  must  be  a  subtype  of  Texp{.  The 
type  of  the  record-set!  expression  is  unit. 

Effect  Information:  The  overall  effect  of  the  record- set!  expression  is 
the  maxet f  of  the  write  effect  on  the  region  Rexp  associated  with  txpx  and 
the  effect  of  evaluating  txpx  and  exp2. 

Example: 

;;  Changing  Joe's  address. 

•  t 

(record-set!  joe  address  "Big  Blue,  Yorktown") 
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3.18  Oneofs 

The  notion  of  tagged  variant,  or  discriminated  union,  is  provided  in  FX  by 
the  oneol  type  constructor.  There  are  three  special  forms  for  manipulating 
oneof  values:  one,  tagcase  and  one -set ! . 
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(oneof  ((ni  Tezp2)  (n2  Tezp2). . .  ( nm  Texpm))  Rezp) 


Semantics:  This  is  the  type  of  a  oneof  value  defined  in  the  region  Rezp 
and  whose  possible  tags  (identifiers)  with  associated  contents  types  are  («i 
TezPl),  (n2  Tezpi),  . . .  (nm  Texpm). 

The  tags  appearing  in  the  oneof  type  must  be  distinct.  The  order  of  the 
tags  appearing  in  oneof  type  is  irrelevant. 

A  oneof  type  (oneof  ((r»i  Tezpn)  (n2  Tezp12)  ...(nm  Texplm ))  RexpJ 
is  a  subtype  of  (oneof  ((pi  Tezp2l)  (p2  Tezp22)  . . .  (p,  Tezp2q))  Rezp2)  iff 
m  <  q,  for  each  field  name  n,-  there  is  a  j  such  that  n,-  =  p;  and  either 

1.  Rexpi  is  a  subregion  of  Rezp2 

2.  for  each  field  name  n,-  and  corresponding  pj ,  Texplf-  is  interconvertible 
to  Tezp2j 

or 

1.  Rezp1  —  Rezp2  = 

2.  for  each  field  name  n,-  and  corresponding  pj,  Tezpu  is  a  subtype  of 
Tezp2j 

There  ;s  no  literals  for  oneof  values. 

Kind  Information:  The  kind  of  a  oneof  expression  is  type. 

Example: 

; ;  The  type  of  a  basket . 

»  i 

(oneof  ((oranges  int) 

(apples  int)) 

CMarket) 


S  .’  , 


one 


value  expression 


'  v 
J 


(one  Tezp  n  exp) 


Semantics:  The  one  expression  is  used  to  create  new  oneof  values.  The  tag 
n  must  be  one  of  the  tags  appearing  in  Texp,  which  must  be  a  oneof  type. 
A  new  oneof  value  of  type  Texp  is  allocated.  The  tag  of  the  new  value  is 
n  and  its  contents  is  the  result  of  the  evaluation  of  exp,  the  type  of  which 
must  be  a  subtype  of  the  type  corresponding  to  n  in  Texp.  The  result  of  the 
one  expression  is  the  newly  allocated  oneof  value. 

Type  Information:  The  type  of  the  one  expression  is  Texp. 

Effect  Information:  The  effect  of  the  one  expression  is  the  maxeff  of 
(alloc  Rexp)  and  the  effect  of  evaluating  exp,  where  Rexp  is  the  region 
parameter  of  the  oneof  type  Texp. 

Example: 

;;  Creating  a  oneof  representing  3  apples. 

9  • 

(let  ((basket  (one  (oneof  ((apples  lnt)  (oranges  int)) 

•Market) 
apples  3))) 


basket) 


tagcase 


vaiue  expression 


I 


■4 


(tagcasa  var 

(»i  e*Pu  exPu  •••) 

(na  exp2l  exp22 

[(else  expml  expm2  ...)]) 
or 

(tagcase  (var  exp  [Rexpvar]) 

(n i  expn  expu  ...) 

(n2  expji  exp22 

[(else  expml  expm2  ...)]) 

All  n,-  must  be  distinct. 

Semantics:  The  tagcase  expression  selects  one  of  the  clauses  (n,  ezptl 
expi2  . . .)  according  to  the  tag  of  a  oneof  value.  Two  different  forms  are 
allowed,  either  with  var  or  (var  exp  \Rexpuar\).  In  the  first  case,  the  var  is 
evaluated  and  must  have  a  oneof  type.  In  the  second  case,  exp  is  evaluated 
and  bound  to  var,  which  is  allocated  in  Rexpvar  (or  C*  if  omitted);  exp  must 
have  a  oneof  type. 

If  there  is  a  clause  which  has  the  same  tag  n«  as  v,  the  value  of  var,  then 
(begin  expu  exPn  ■  •  • )  “  evaluated  in  an  environment  in  which  var  is  bound 
to  the  contents  of  v.  Otherwise,  (begin  expml  expm2  . . .)  is  evaluated. 

Type  Information:  Let  the  oneof  type  of  var  be  of  the  form  (oneof  ((mi 
Texp1 )  (m2  Texp2). . . )  Rexp).  Then,  each  tag  n,-  must  be  one  of  the  my. 
Each  my  must  appear  exactly  once,  unless  an  else  clause  is  given,  in  which 
case  some  of  the  my  may  be  omitted.  Within  the  t’th  clause,  the  type  of  var 
is  Texpj  if  n,  is  my.  Within  an  else  clause,  the  type  of  var  is  unchanged  if 
Rexp  is  mutable,  otherwise  its  oneof  type  is  restricted  to  those  fields  that 
don’t  appear  as  tags  of  clauses. 

The  type  of  a  tagcase  expression  is  the  maximum  of  the  types  of  the 
last  expressions  in  each  clause. 

Effect  Information:  The  effect  of  the  tagcase  expression  is  the  maxeff 
of  (read  Rexp),  (alloc  Rexpvar)  and  the  effects  of  evaluating  erp^y  and,  if 
present,  exp. 
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tagc&se  (continued) 


value  expression 


k 


;;  Evaluating  the  quality  of  a  basket. 
«  • 

(tagcase  basket 

(apples  "Great  !") 

(oranges  "Well  ...")) 


one -set! 


va lue  expression 


(one-set!  ezp2  n  ezp2) 


Semantics:  The  one-set!  expression  mutates  the  tag  and  contents  of  a 
oneof  value,  which  must  be  located  in  a  mutable  region.  exp1  and  exp2  are 
evaluated  successively  to  yield  values  v%  and  v2.  The  tag  and  contents  of  vi 
are  mutated  to  n  and  v2  respectively.  The  result  of  the  one -set!  expression 
is  #u. 

Type  Information:  ezp1  must  have  type  (oneof  ((r»i  Tezp («2  Texp2) 
. . .  (nm  Texpm))  Rcxp)  where  Rezp  is  a  mutable  region.  The  tag  n  must  be 
the  same  as  some  «v  The  type  of  exp2  must  be  a  subtype  of  Ttxpi .  The 
type  of  the  one -set!  expression  is  unit. 

Effect  Information:  The  effect  of  the  one-set!  expression  is  the  maxeff 
of  (write  Rexp)  and  the  effect  of  evaluating  exp1  and  exp2 . 

Example: 

;  Changing  the  basket  to  oranges . 

■  i 

(one-set!  basket  oranges  4) 
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Chapter  4 

FX  Syntactic  Sugar 


This  chapter  describes  a  set  of  special  forms,  called  syntactic  sugars,  that  are 
not  strictly  necessary  for  writing  FX  programs  but  that  represent  common 
idioms  of  programming.  These  constructs  can  be  translated,  or  de-sugared, 
into  other  FX  constructs  by  simple  syntactic  transformations.  They  are 
provided  in  the  FX  language  as  a  convenience  for  the  programmer. 

The  following  descriptions  are  arranged  in  alphabetical  order  for  easy 
reference:  and,  cond,  diet,  diet*,  do,  let,  let*,  plet*  and  or. 


and 


value  expression 


(and  expi  . . .  expn) 


Semantics:  This  form  performs  the  “and”  evaluation  of  boolean  expres¬ 
sions  using  a  “short-circuit”  technique. 

Every  expression  ezp,  is  successively  evaluated.  As  soon  as  #f  is  returned 
by  one  eip,,  the  evaluation  of  the  (possibly)  remaining  expressions  is  aban¬ 
doned  and  #1  is  returned.  If  all  the  expi  return  #t,  then  #t  is  the  value  of 
the  and  expression.  By  convention,  (and)  evaluates  to  #t. 

Type  Information:  Each  exp{  must  be  of  type  bool,  which  is  the  type  of 
the  whole  expression. 

Effect  Information:  The  effect  of  the  and  construct  is  the  maxeff  of  the 
effects  of  evaluating  expt. 

Sugar  Information:  The  above  and  expression  is  equivalent  to: 

(if  ex p!  (if  . . .  (if  expn  #t  #f)  . . .)  #f) 

Example: 

;;  A  test  for  valid  vector  indices. 

(and  (>■  index  0) 

(<  index  (vector-length  v)) 

(■  (vector-ref  v  index)  0)) 
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(cond  (ezpteiti  expn  . . .  ezpln) 

(**Pu.tk  exPki  ■■■e*Pk m) 

(else  exp{k+l)l  . . .  exp(k+ l)p)) 

Semantics:  The  cond  special  form  is  a  multiple-way  test  expression.  The 
expressions  ezpUttj  are  successively  evaluated  and  as  soon  as  one  returns  #t 
(or  the  else  clause  is  reached),  the  associated  expressions  are  evaluated  as 
if  they  were  inclosed  in  a  begin  special  form. 

Type  Information:  The  expressions  expUlti  must  be  of  type  bool.  The 
type  of  a  cond  expression  is  the  maximum  of  the  types  of  the  last  expressions 
in  each  branch  (namely  ezpln  . . .). 

Effect  Information:  The  effect  of  the  cond  construct  is  the  maxef  f  of  the 
effects  of  all  the  expUtti  and  exp^ . 

Sugar  Information:  The  above  cond  expression  is  equivalent  to: 

(if  expUltl 

(begin  expn  . . .  expin) 

(if... 

(if  expUltk 

(begin  expkl  . . .  expkm) 

(begin  txp{k+l)l  . . .  exP{k+1]p)). . .)) 

Example: 

;;  The  addition  function. 

»  • 

(letrec  ((add  (lambda  ((n  int)  (m  int)) 

(the  pure  int 

(cond  ((<  n  0)  0) 

((-  n  0)  m) 

(else  (add  (-  n  1) 

(+  m  1)))))))) 


(add  1  2)) 


L> 


,  •*/>!! 

m 


description  expression 


(diet  ((<t,  Dexpi)...)  Dexp^) 


The  di  must  all  be  distinct. 


Semantics:  diet  provides  a  means  of  introducing  synonyms  for  type,  ef¬ 
fect,  and  region  expressions.  The  value  of  a  diet  description  expression 
is  a  description  expression,  namely  Dtxp^ody  with  the  di  replaced  by  the 
corresponding  Z?ezp,-. 


Kind  Information:  The  kind  of  the  diet  description  expression  is  the  kind 
of  Dezpiody  with  each  di  replaced  by  Dezpi. 


Sugar  Information:  The  diet  description  expression  is  equivalent  to: 


((d lambda  ((di  Kexp^). . .)  DezpMy)  Dezpl. . .) 
assuming  that  the  kind  of  Dezpi  is  Kezp{. 


Example: 


The  type  of  a  subroutine  which  takes  two  binary  operations 
on  bools,  two  booleans  and  returns  whichever  one  returns 
#t  (say). 


(diet  ((subr-type  (subr  pure  (bool  bool)  bool))) 

(subr  pure  (subr-type  subr-type  bool  bool)  subr-type)) 


diet* 


description  expression 


(diet*  (( di  Dexpx)...)  Dexpbody) 


Semantics:  diet*  provides  a  means  of  introducing  synonyms  for  type,  ef¬ 
fect,  and  region  expressions. 

The  value  of  a  diet*  description  expression  is  the  value  of  its  body. 
Whenever  di  is  encountered  in  the  diet*  body,  it  is  replaced  by  Dezpi.  A 
reference  to  a  <£,  in  Dexpj  is  taken  to  refer  to,  either  a  previous  binding  of 
di  in  the  current  diet*  (if  such  binding  exists),  or  a  binding  for  di  in  the 
surrounding  (outer)  scope. 

Kind  Information:  The  kind  of  the  diet*  description  expression  is  the 
kind  of  Dexpkody  with  each  di  replaced  by  Dtxp{ . 

Sugar  Information:  The  diet*  description  expression  is  equivalent  to: 
(diet  ((4  Dezpi))  (diet*  (...)  Dexpiody)) 


Example: 

; ;  The  type  of  a  subroutine  which  takes  two  binary  operations 
; ;  on  bools ,  two  booleans  and  returns  whichever  one  returns 
; ;  #t  (say) . 

•  » 

(diet*  ((t  bool) 

(subr-type  (subr  pure  (t  t)  t))) 

(subr  pure  (subr-type  subr-type  t  t)  subr-type)) 


do 


value  expression 


(do  ((war i  expinitl  [ exp^  [««*Pi]]). .  ) 

(exPt*H  exPrtnl  ezPrtn3-  ■  ■  exPrinn) 
eXPlcdy\  •  •  • ) 

The  van  must  all  be  distinct. 

Omitting  ezpttepi  is  the  same  as  writing  van  there  (i.e.,  (var*  expiniti )  is 
the  same  as  (van  exPinit%  var*)). 


Semantics:  do  expressions  are  used  for  performing  iterations.  They  define 
a  set  of  iteration  variables,  which  are  new  variables  allocated  in  Rezpi  (or 
if  omitted) ,  with  initial  values  for  those  variables  and  (optionally)  expressions 
for  updating  them. 

There  are  three  parts  to  the  evaluation  of  a  do  expression:  the  initializa¬ 
tion,  the  iteration,  and  the  return. 

During  the  initialization,  the  ezpiniti  are  evaluated  from  left  to  right  and 
the  resulting  values  are  bound  to  the  corresponding  var*.  These  vari  are  not 
available  for  use  in  the  ezpiniti . 

At  the  beginning  of  every  iteration,  ezpUlt  is  evaluated.  If  the  test  returns 
#1,  then  the  ezpiodyi  are  evaluated  in  order.  Then,  the  ezptUpi  are  evaluated 
from  left  to  right  and  the  results  are  bound  as  new  values  for  the  var*. 
Iteration  then  starts  over  again. 

If  expUtt  returns  #t  at  the  beginning  of  an  iteration,  then  the  result  of 
the  evaluation  of  (begin  ezprtnl  ezprtn2  . . . )  is  returned. 

Type  Information:  The  expression  ezpUtt  must  be  of  type  bool.  Each 
var*  has  the  same  type  as  exp*****.  The  type  of  each  ezpltepi  must  be  a 
subtype  of  the  type  of  var*.  The  type  Tezp ^  of  the  do  expression  is  the  type 
of  the  last  return  expression,  ezprtnn. 

Effect  Information:  The  effect  Eexp ^  of  a  do  expression  is  computed  by 
performing  effect  masking  on  the  a  axe  If  of  the  effects  of  the  eip*n*t* ,  the 
exP,tepi>  exPte»t >  the  exprtni,  the  expMyi,  and  (alloc  Rezpi). 
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do  (continued) 


value  expression 


Sugar  Information:  The  above  do  expression  is  equivalent  to: 

(letrec  ((do-temp 

(lambda  ((vari  Texpl  Rexpt). . . ) 

(the  Eezpfo  Texp ^ 

(if  expu,t 

(begin  exprtnl 

exPrM  •  •  • 
exPrtnn) 

(begin  expbodyl  . . . 

(do-temp  exp,tepl  ...))))))) 

(do-temp  expinitl  ...)) 

where  Texpi  is  the  type  of  expiniti  and  do-temp  is  a  new  identifier. 
Example: 

;;  Loop  until  foo?  is  verified  and  then  return  the  toggle. 

i  i 

(do  ((toggle  #t  (not  toggle))) 

((foo?  toggle)  toggle) 

) 


let 


value  expression 


(let  ((van  expx  [ffexpi])...)  explh  exp». . .) 

The  body  of  the  let  expression,  expn  expu. . . ,  is  treated  as  though 
(begin  expu  ex pu. . .)  is  written. 

The  var,-  must  all  be  distinct. 

Semantics:  let  provides  a  way  for  creating  synonyms,  or  shorthand  names, 
for  complicated,  lengthy,  or  computationally  expensive  expressions. 

The  body  of  the  let  expression,  the  expressions  exp is  evaluated  with 
each  of  the  variables  var,-,  allocated  in  Rexpt  (or  0*  if  omitted),  denoting  the 
value  resulting  from  the  evaluation  of  its  corresponding  expi.  A  reference 
to  one  of  the  var*  within  these  expressions  is  interpreted  as  a  reference  to 
a  binding  for  that  var,-  in  the  surrounding  (outer)  scope  of  let  (see  the 
description  of  letrec  for  a  discussion  of  recursion). 

The  value  of  the  let  expression  is  the  value  of  its  body  evaluated  in  this 
way. 

Type  Information:  The  type  of  the  let  expression  is  the  type  of  its  body. 

Effect  Information:  The  effect  of  a  let  expression  is  the  maxeff  of  the 
effects  of  the  expit  the  expik,  and  (alloc  Rexpi). 

Sugar  Information:  A  let  expression  is  equivalent  to  an  application  of  a 
lambda  expression.  The  above  let  expression  is  equivalent  to: 

((lambda  ((van  Texpl  (ffe*Px]). . .)  explb  expu. . .)  e*px- . .) 

assuming  that  the  types  of  ezp{  is  Texp ,. 

Example: 

;  Avoid  a  double  (expensive)  computation. 

■  ■ 

(let  ((y  (expensive-computation))) 

(foo  y  y)) 
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let* 


value  expression 


(let*  ((eari  expx  [Rezp!])...)  ezplh  exp3i. . .) 

The  body  of  the  let*  expression,  explh  txpu. . . ,  is  treated  as  though 
(begin  ezpxi  exp2i . . .)  is  written. 

Semantics:  let*  provides  a  way  for  creating  synonyms,  or  shorthand  names, 
for  complicated,  lengthy,  or  computationally  expensive  expressions. 

The  body  of  the  let*  expression,  the  expressions  expjt,  is  evaluated  with 
each  of  the  var,-,  allocated  in  Rezp{  (or  C*  if  omitted),  denoting  the  value 
resulting  from  the  evaluation  of  its  corresponding  txpi.  A  reference  to  one 
of  the  var,-  within  these  expressions  is  interpreted  as  a  reference  to,  either 
a  previous  binding  of  var,-  in  the  current  let*  (if  such  binding  exists),  or 
a  binding  for  that  var<  in  the  surrounding  (outer)  scope  of  let*  (see  the 
description  of  letrec  for  a  discussion  of  recursion.) 

The  value  of  the  let*  expression  is  the  value  of  its  body  evaluated  in 
this  way. 

Type  Information:  The  type  of  the  let*  expression  is  the  type  of  its  body. 

Effect  Information:  The  effect  of  a  let*  expression  is  computed  by  per¬ 
forming  effect  masking  on  the  aaxeff  of  the  effects  of  the  exp,-,  the  expit, 
and  (alloc  Rexpt). 

Sugar  Information:  A  let*  expression  is  equivalent  to  a  nested  list  of 
let.  The  above  let*  expression  is  equivalent  to: 

(let  ((varj  expx  [flexpxl)) 

(let*  (...)  ezplt  exp3i. . .)) 


Example: 

Avoid  a  double  (expensive  and  voluminous)  computation. 

i  » 

(let*  ((y  (voluminous-expression)) 

(y  (expensive-computation  y))) 

(foo  y  y)) 
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value  expression 


(or  ex?!  . . . exp„) 


Semantics:  This  form  performs  the  "or”  evaluation  of  boolean  expressions 
using  a  “short-circuit”  technique. 

Every  expression  exp^  is  evaluated  in  turn  proceeding  from  left  to  right. 
As  soon  as  one  of  the  expi  evaluates  to  it,  the  evaluation  of  the  (possibly) 
remaining  expressions  is  abandoned  and  it  is  returned.  If  all  the  exp,  return 
if,  then  if  is  returned.  By  convention,  (or)  evaluates  to  if. 


Type  Information:  All  of  the  exp,  must  be  of  type  bool.  The  type  of  an 
or  expression  is  bool. 


Effect  Information:  The  effect  of  the  or  construct  is  the  aaxeff  of  the 
effects  of  evaluating  the  exp,-. 


Sugar  Information:  The  above  or  expression  is  equivalent  to: 


(if  expi  it  (if  ...  (if  expn  it  if). . .)) 


Example: 


;  A  debug-only  test . 


(or  *debug-phase* 

(to-be-tested-latter) ) 


vS*ro 


plet* 
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(plet*  ((</i  Dexpi)...)  expi  exp2. . .) 

The  body  of  the  plet*  expression,  exp1  exp2. . . ,  is  treated  as  though 
(begin  expi  ex p2. . .)  is  written. 

Semantics:  plet*  provides  a  way  of  making  type,  effect,  region  and  de¬ 
scription  function  synonyms,  or  shorthand  names,  for  complicated  descrip¬ 
tion  expressions. 

The  value  of  a  plet*  value  expression  is  the  value  of  its  body.  Whenever 
di  is  encountered  in  the  plet*  body,  it  is  replaced  by  Dexp{.  A  reference 
to  a  di  in  Dexpj  is  taken  to  refer  to,  either  a  previous  binding  of  di  in  the 
current  plet*  (if  such  binding  exists),  or  a  binding  for  di  in  the  surrounding 
(outer)  scope.  (See  the  description  of  pletrec  for  a  discussion  of  recursive 
types.) 

Type  Information:  The  type  of  the  plet*  expression  is  the  type  of  its 
body  with  Dexpi  substituted  for  di. 

Effect  Information:  The  effect  of  the  plet*  expression  is  the  effect  of  its 
body  with  Dexp{  substituted  for  di. 

Sugar  Information:  The  plet*  value  expression  is  equivalent  to: 

(plet  ((^  1 Dexpj)  (plet*  (...)  expx  exp2. . .)) 

Example: 

;;  The  identity  function  on  a  complicated  type. 

>  i 

(plet*  ((t  (subr  pure  (bool)  bool)) 

(t  (ref  t  Cl))) 

(lambda  ((a-ref -to-subr  t))  a-ref -to-subr) ) 
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Chapter  5 


The  FX  Environment 


We  describe  in  this  chapter  the  FX  programming  environment,  which 
includes  input  and  output  operations,  an  error-signalling  facility,  an 
interpreter-oriented  top-level,  and  a  simple  way  to  structure  large  FX  pro¬ 
grams.  These  primitive  facilities  will  be  supported  by  every  FX  implemen¬ 
tation. 


5.1  I/O  Facilities 

The  I/O  fun  .^ions  deal  with  a  new  value  in  the  FX  system,  namely  the  file 
system. 


Definitions 

This  subsection  introduces  two  new  types:  input -port  and  output -port, 
both  of  kind  type.  FX  uses  ports  as  an  abstraction  for  files,  where  values 
of  type  input-port  are  used  for  read  operations  and  output-port  for  write 
operations. 

I/O  operations  have  effects  on  the  CIO  region.  The  region  CIO  is  used  to 
describe  the  state  of  the  file  system  and  the  input  and  output  file  pointers. 

Literals 

There  are  no  literals  of  type  input -port  or  output -port. 
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Operations 

FX  provides  a  set  of  I/O  subroutines  that  are  compatible  with  the  Scheme 
I/O  primitives.  Since  the  FX  input  and  output  subroutines  are  duals  of  one 
another,  we  only  define  the  types  of  input  subroutines.  In  order  to  compute 
the  types  of  output  subroutines  (the  names  of  which  are  given  in  braces), 
replace  input  by  output  in  the  definitions. 

call-with-input-f ile  {call-with-output-f ile} : 

(poly  ((r  region)) 

(poly  ((t  type)  (e  effect)) 

(subr  (maxeff  e  (alloc  CIO)  (read  r)) 

((string  r)  (subr  e  (input -port)  t)) 
t))) 

current -input -port  {current-output-port}  : 

(subr  (maxeff  (write  CIO)  (read  *10))  ()  input-port) 

Every  running  FX  program  inherits  from  the  environment  an  initial  value 
for  (current -input -port)  and  ( current -output -port ),  initially  bound  to 
the  keyboard  and  the  console. 

with-input-from-file  {with-output-to-f ile}  : 

(poly  ((r  region)) 

(poly  ((t  type)  (e  effect)) 

(subr  (maxeff  (write  CIO)  (read  CIO) 
e  (read  r)  (alloc  CIO)) 

((string  r)  (subr  e  ()  t)) 
t))) 

open-input-file  {open-output-file}  : 

(poly  ((r  region)) 

(subr  (maxeff  (alloc  CIO)  (read  r) 

(write  CIO)  (read  CIO)) 

((string  r))  input-port)) 

close-input-port  {close -output -port}  : 

(subr  (maxeff  (read  CIO)  (write  CIO))  (input-port)  unit) 

char-ready? 

(vsubr  (maxeff  (read  CIO)  (write  CIO))  input-port  bool) 
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Read  functions  are  provided  for  each  basic  type.  A  dynamic  error  will 
be  signalled  if  the  type  of  the  value  to  be  read  is  not  correct.  These  read 
functions  use  the  current  input-port  to  perform  their  I/O  operation. 

read-bool  : 

(subr  (maxeff  (write  CIO)  (read  CIO))  ()  bool) 
read-char  : 

(subr  (maxeff  (write  CIO)  (read  CIO))  ()  char) 
read-int  : 

(subr  (maxeff  (write  CIO)  (read  CIO))  ()  int) 
read-float  : 

(subr  (maxeff  (write  CIO)  (read  CIO))  ()  float) 
read- string  : 

(subr  (maxeff  (write  CIO)  (read  CIO))  ()  (string  C“)) 
read- symbol  : 

(subr  (maxeff  (write  CIO)  (read  CIO))  ()  symbol) 

It  is  a  dynamic  error  to  perform  a  read  operation  if  the  end  of  file  of  the 
current  input  port  is  reached.  The  presence  of  the  end  of  file  for  the  current 
input  port  can  be  tested  by  the  eof?  function: 

eof?  (subr  (maxeff  (write  CIO)  (read  CIO))  ()  bool) 

FX  also  provides  a  set  of  type  specific  write  subroutines  which  use  the 
current  output-port. 

write -bool  : 

(subr  (maxeff  (write  CIO)  (read  CIO))  (bool)  unit) 
write-char  : 

(subr  (maxeff  (write  CIO)  (read  CIO))  (char)  unit) 
write -int  : 

(subr  (maxeff  (write  CIO)  (read  CIO))  (int)  unit) 
write-float  : 

(subr  (maxeff  (write  CIO)  (read  CIO))  (float)  unit) 
write-string  : 

(poly  ((r  region)) 

(subr  (maxeff  (write  CIO)  (read  CIO)  (read  r)) 

((string  r)) 
unit) ) 

write-symbol  : 

(subr  (maxeff  (write  CIO)  (read  CIO))  (symbol)  unit) 
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In  addition  to  these  subroutines  for  specific  data  types,  FX  provides 
general  symbolic  expression  input  and  output  via  the  sexp  type: 

(dletrec  ((sexp  (oneof  ((s-unit  unit) 

(s-bool  bool) 

(s-int  int) 

(s-float  float) 

(8 -char  char) 

(s-synbol  symbol) 

(s-string  (string  C-)) 

(s-vecfcorof  (vect orof  sexp  €*)) 

(s-null  null) 

(s-pairof  (pairof  sexp  sexp  0«))) 

«-))) 

sexp) 

Two  subroutines  are  provided  to  read  a  write  sexp  values: 

read-sexp  (subr  (maxeff  (read  CIO)  (write  CIO))  ()  sexp) 
write-sexp  :  (subr  (maxeff  (read  CIO)  (write  CIO))  (sexp)  unit) 

Every  sexp  value  has  a  literal  value  which  when  written  by  write-sexp 
can  be  read  back  in  by  read-sexp.  The  concrete  syntax  used  foi  Bexp  literals 
is  the  one  used  by  FX  for  unit,  bool,  int  (in  base  10),  float,  char,  (string 
C»)  and  null  values,  symbol  literals  are  identifiers  with  the  same  name  as 
the  symbol,  vectorof  literals  are  be  enclosed  between  the  delimiters  #(  and 
).  pairof  literals  are  enclosed  between  the  delimiters  (  and  ). 

5.2  Signalling  Errors 

The  error  subroutine  displays  an  optional  message  and  signals  a  dynamic 
error.  A  call  to  error  does  not  return  and  is  handled  in  an  unspecified 
manner. 

error  :  (poly  ((r  region)) 

(subr  (read  r)  ((string  r))  void)) 

Note  that  there  is  no  way  to  continue  a  computation  once  error  is  called. 
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5.3  Top-Level 

The  FX  top-level  is  a  read-check-eval-print  loop.  As  each  expression  is  input 
by  the  user,  it  is  processed  by  each  of  the  four  stages  of  this  loop: 

•  The  reader  reads  the  expression  and  checks  its  syntax. 

•  The  type  and  effect  system  checks  the  type  and  the  effect  of  the  ex¬ 
pression.  If  a  static  error  is  detected  the  user  is  informed  and  control 
is  returned  to  the  reader  which  waits  for  another  expression. 

•  The  evaluator  evaluates  the  expression  and  computes  its  result  value. 

•  The  printer  outputs  the  result  value  (in  an  unspecified  format),  and 
calls  the  reader  which  waits  for  another  expression. 

The  current  state  of  the  FX  interpreter  is  defined  by  the  definition  en¬ 
vironment,  which  is  a  list  of  description  definitions  (bindings  of  description 
variables  to  description  values)  and  ordinary  definitions  (bindings  of  ordinary 
variables  to  ordinary  values). 

Additional  top-level  definitions  can  be  created  by  the  define  and  pdef  ine 
top-level  special  forms,  respectively: 

•  A  define  special  form  binds  (or  rebinds)  new  values  to  top-level  vari¬ 
ables; 


•  A  pdef  ine  special  form  binds  new  description  values  to  description 
variables. 

The  FX  top-level  process  is  structured  as  the  analysis  of  a  sequence  of 
definition  blocks  and  ordinary  expressions,  which  may  be  interleaved  arbi¬ 
trarily.  A  definition  block  is  a  sequence  of  pdef  ine  and  define  expressions. 
The  FX  type  and  effect  system  stays  inactive  while  a  definition  block  is  being 
entered.  As  soon  as  a  definition  block  is  complete  it  is  evaluated  in  order  to 
update  the  current  definition  environment.  A  definition  block  is  considered 
to  be  complete  either  when  an  ordinary  (value)  expression  is  entered,  or 
when  the  FX  top-level  detects  that  no  pending  undefined  variables  remain. 

When  a  definition  block  is  complete  it  is  evaluated  in  the  following  man¬ 
ner.  First,  every  new  description  binding  is  added  to  the  list  of  description 
definitions.  It  is  a  static  error  to  attempt  to  rebind  a  description  variable 
if  the  new  description  is  not  convertible  to  the  old  one.  Second,  every  new 
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ordinary  binding  is  added  to  the  list  of  ordinary  definitions.  It  is  a  static 
error  to  attempt  to  rebind  an  ordinary  variable  if  the  type  of  the  new  value 
is  not  a  subtype  of  the  type  of  the  old  one. 

If  a  static  error  occurs  during  the  evaluation  of  a  definition  block,  the 
definition  block  is  abandoned  and  the  definition  environment  is  restored  to 
its  state  before  the  present  definition  block  was  entered. 

When  ordinary  expressions  expy  . . .  are  entered  after  zero  or  more  defi¬ 
nition  blocks,  they  are  evaluated  sequentially  as  if  in  the  body  of  a  pletrec 
expression  formed  with  the  list  of  description  definitions  present  in  the  up¬ 
dated  definition  environment,  and  a  letrec  expression  formed  with  the  list 
of  ordinary  definitions  from  the  updated  definition  environment. 

The  initial  definition  environment  includes  all  of  the  standard  types  and 
variables  defined  in  this  manual. 


define 


top-level  expression 


(define  var  exp ) 
or 

(define  (ear  (vari  Texp1  [Rexp^])  . ..)  expt  exp2. . .) 

The  second  form  is  equivalent  to 

(define  var  (lanbda  ((vari  Texpx  [ Rexp x])  ...)  exp2  exp2. . .)) 

and  so,  the  following  description  only  deals  with  the  first  form. 

This  special  form  is  allowed  only  at  the  top-level  of  FX. 

Semantics:  The  define  special  form  extends  the  current  set  of  ordinary 
variable  definitions  which  are  visible  at  the  top-level.  Specifically  var  is 
bound  in  the  region  C“  to  the  value  of  the  expression  exp.  If  var  is  already 
bound,  the  previous  binding  is  lost  and  the  other  ordinary  definitions  that 
used  the  previous  binding  of  var  now  refer  to  this  new  version. 

If  var  is  already  bound,  the  type  of  exp  must  be  a  subtype  of  the  type  of 
var. 

At  any  given  time,  the  set  of  defined  ordinary  variables  is  logically  em¬ 
bedded  in  an  enclosing  letrec  form,  so  the  restrictions  imposed  by  this  form 
must  be  observed  when  using  the  define  special  form. 

Examples: 

; ;  An  add2  function  with  a  forward  reference. 

i  i 

(define  add2  (lanbda  ((x  int)) 

(the  pure  int 

(addl  (addl  x))))) 

;;  And  now,  the  addl  function. 

•  • 

(define  (addl  (x  int)) 

(the  pure  int  (♦  x  1))) 
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top-level  expression 


(pdef  ine  d  Dexp ) 
or 

(pdef ine  ( d  (A\  Kexpt)  . . .)  Dexp) 

The  second  form  is  equivalent  to 

(pdeline  d  (dlanbda  ((d\  Kexp{)  . ..)  Dexp)) 

and  so,  the  following  description  will  only  deal  with  the  first  form. 

This  special  form  is  allowed  only  at  the  top-level  of  FX. 

Semantics:  This  special  form  extends  the  current  set  of  description  variable 
definitions  which  are  visible  at  the  top-level;  specifically,  d  is  bound  to  the 
description  expression  Dexp. 

If  d  is  already  bound,  Dexp  must  be  convertible  to  the  old  value  of  d. 
At  any  given  time,  the  set  of  defined  description  variables  is  logically 
embedded  in  an  enclosing  pletrec  form,  so  the  restrictions  imposed  by  this 
form  must  be  observed  when  using  the  pdef  ine  special  form. 

Example: 

;;  Define  the  list-of-int  type. 

»  i 

(pdefine  list-of-int  (listof  int  Cay-lists)) 
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Structuring  programs 


The  FX user  may  want  to  use  different  FX files  to  develop  large  FX programs. 
The  following  special  forms  provide  the  ability  to  deal  with  this  kind  of 
incremental  program  development:  load  and  compile. 
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load 


top-level  expression 


(load  string-literal) 

The  load  special  form  is  allowed  only  at  the  top-level  of  FX. 

Semantics:  The  load  special  form  enters  the  contents  of  the  specified  file 
into  FX  as  if  they  had  been  typed  interactively  at  top-level,  except  in  the 
way  that  FX  behaves  if  an  error  is  signalled.  If  an  error  is  signalled  during  a 
load  operation,  the  current  definition  block  is  abandoned  and  the  definition 
environment  is  restored  to  what  it  was  before  the  current  block;  the  top-level 
is  then  restarted,  load  can  be  included  in  files  that  are  loaded.  The  format 
of  the  file  name  string  is  not  specified. 

Example: 

; ;  Loading  the  init.lx  file. 

t  i 

(load  "psrg:>fx>init.fx") 
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compile  top-level  expression 

(compile  string-literal) 

The  compile  special  form  is  allowed  only  at  the  top-level  of  FX. 

Semantics:  The  compile  special  form  creates  an  optimized  version  of  the 
program  in  the  specified  file.  This  optimized  version  will  be  used  the  next 
time  the  specified  file  is  loaded.  The  compile  form  does  not  alter  the  defi¬ 
nition  environment.  The  format  of  the  file  name  string  is  not  specified. 

Example: 

;;  Compile  the  lnit.fx  file. 

(compile  "pmrg:>fx>init.fx") 
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Appendix  A 

FX  Syntax 


This  appendix  gives  the  syntax  of  FX  as  a  BNF  grammar.  For  the  purposes 
of  this  grammar,  id  denotes  an  identifier,  var  a  variable,  integer  a  non-empty 
sequence  of  digits  and  character  a  character. 


Kexp  =  -  Kind  expressions 

region  |  effect  |  type 
(df  unc  {Kexp. . . )  Kexp) 


Dexp  =  -  Description  expressions 

Rexp  j  Eexp  |  Texp  \  HDcac 


HDeac  =  -  Higher  order  description  expressions 

GDeac 

(dlambda  ((var  Kexp). . .)  Dexp) 


GDeac  =  -  Generic  description  expressions 

var 

{HDeac  Dexp.  .  .) 

(diet  ((var  Dexp). . .)  Dexp) 

(diet*  ((var  Dexp).  .  .)  Dexp) 

(dletrec  ((var  Dexp).  .  .)  Dexp ) 
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I  Rexp  =  -  Region  expressions 

*  GDeac 

|  C  id 

|  (runion  Rexp  Rexp  . . . ) 

i 

I 

Eexp  =  -  Effect  expressions 

GDeac 
pore 

(alloc  Rexp) 

(read  Rexp) 

(write  Rexp) 

(maxeff  Eexp...) 


Texp  =  -  Type  expressions 

GDeac 

bool  |  char  j  float  |  Int 
null  |  symbol  |  unit|  void 
(subr  Eexp  (  Texp. . . )  Texp) 

(poly  ((war  Kexp). . .)  Texp) 

(ref  Texp  Rexp) 

(string  Rexp) 

(pairof  Texp  Texp  Rexp) 

(listof  Texp  Rexp) 

(vsnbr  Eexp  Texp  Texp) 

(promise  Eexp  Texp) 

(uniqueof  Texp) 

(vectorof  Texp  Rexp) 

(recordof  ((ear  Texp)  ...)  Rexp) 

(oneof  ((var  Texp)  (var  Texp)...)  Rexp) 


TopLevel  =  -  Top  Level  Value  expressions 

(define  var  exp) 

(define  (var  (var  Texp  [Jiezp]). . .)  exp  exp. . . ) 

(pdefine  var  Dexp) 

(pdef  ine  (var  (var  Kexp). . .)  Dexp) 
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(load  "character. ..") 
(compile  "character. . 


-  Value  expressions 


Literal 
(exp  exp. . .) 

(and  exp. . .) 

(begin  exp  exp. . .) 

(cond  ( exp  exp  exp. . .). .  .(else  exp  exp. . .)) 

(delay  exp) 

(do  ((var  exp  [exp  [Rexp]]). . .)  (exp  exp  exp. . .)  exp. . .) 

(if  exp  exp  exp ) 

(lambda  ((var  Texp  [Rexp]). . .)  exp  exp. . .) 

(let  ((var  exp  [Rexp]). . .)  exp  exp. . .) 

(letrec  ((var  exp  [Rexp]). . .)  exp  exp. . .) 

(let*  ((var  exp  [Rexp]). . .)  exp  exp. . .) 

(one  Texp  var  exp) 

(one -set!  exp  var  exp) 

(or  exp. . . ) 

(plambda  ((var  Kexp). . .)  exp) 

(plet  ((var  Dexp). . .)  exp  exp. . .) 

(pletrec  ((var  Dexp). . .)  exp  exp. . .) 

(plet*  ((var  Dexp). . .)  exp  exp. . .) 

(proj  exp  Dexp. . .) 

(record  ((var  exp). . .)  [Rexp]) 

(record-set!  exp  var  exp) 

(select  exp  var) 

(set  I  var  exp) 

(tagcase  var  (var  exp  exp. . .)  (var  exp  exp. 

[(else  exp  exp. . . ))) 

(tagcase  (var  exp  [Rexp])  (var  exp  exp  . . .)  (var  exp  exp.  .  .). 

[(else  exp  exp  .  ..)]) 

(the  [ Eexp ]  Texp  exp) 

(vlambda  (var  Texp  [Rexp])  exp  exp. .  .) 
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Literal  = 


-  Literal  expressions 


#t  |  #f 

[#Sose][Styn]intejer 
[Sign\integer .  integer  [e{Sign]integer\ 
#\Char 
”  character . . .  " 

’ id 

(quote  id) 

() 


Base  =  b  |  o  I  d  I  x 


Sign  =  +  l  - 


Char  =  character  \  backspace  |  newline  |  page  |  space  |  tab 
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Appendix  B 


FX  Semantics 


This  appendix  describes  the  constructs  and  concepts  that  form  the  basis 
of  the  FX  language.  In  particular,  we  state  the  following  claims:  type 
soundness,  static  typing,  location  invariance,  untyped  semantics,  typeless 
implementation,  and  effect  soundness.  The  proofs  are  omitted. 

To  keep  the  presentation  simple,  many  features  not  essential  to  the  theory 
behind  FX  have  been  omitted  from  this  appendix.  These  include  immutable 
regions,  description  functions,  multiple  function  arguments,  implicit  begin 
expressions  (e.g.  inside  lambda),  recursion,  built-in  types  such  as  integers 
and  strings,  data  structuring  types  such  as  records  and  oneofs,  I/O  functions 
and  assignable  variables. 


B.l  Grammar 


The  grammar  of  the  language  described  in  this  appendix  is  given  below, 
starting  with  kinds  and  proceeding  to  descriptions  and  ordinary  expressions. 
For  the  most  part,  this  grammar  generates  the  same  language  as  that  de¬ 
scribed  in  the  previous  appendix.  We  reproduce  an  entire  grammar  here  so 
that  we  may  simultaneously  introduce  some  new  notation  and  the  simplifi¬ 
cations  alluded  to  above. 

The  meta- variable  for  each  syntactic  class  is  shown  in  parentheses.  Meta¬ 
variables  in  this  appendix  differ  from  those  in  the  rest  of  the  manual  so  that 
the  formal  rules  presented  here  have  a  more  compact  representation. 

Kinds  serve  as  the  “types”  of  descriptions.  There  are  three  kinds,  cor¬ 
responding  to  the  three  k  'ids  of  descriptions  —  region,  effect,  and  type 
descriptions. 
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Kind  - 

region 

ellect 

type 


-  kinds  (k) 

-  kind  of  regions 

-  kind  of  effects 

-  kind  of  types 


Descriptions  serve  to  describe  the  types  and  effects  of  ordinary  expres¬ 
sions.  We  discuss  the  three  kinds  of  descriptions  —  region,  effect,  and  type 
descriptions  —  in  turn,  but  first  we  define  the  description  constants  and 
variables. 


Rconst  =  {ri,rj, . . .  } 
Tconst  = {unit, bool} 
Econst  = {pure} 

Dvar  —  {dl,d2,..  } 


-  region  constants  (r) 

-  type  constants  (t) 

-  effect  constants 

-  description  variables  (d) 


Region  descriptions  correspond  to  countably  infinite  sets  of  locations, 
which  we  call  regions.  The  runion  of  one  or  more  region  descriptions  cor¬ 
responds  to  the  union  of  the  corresponding  sets  of  locations.  The  precise 
meaning  of  “locations”  is  given  on  page  134. 


Region  = 

Rconst 

Dvar 

(runion  Region+) 


-  region  descriptions  (p) 

-  region  constant 

-  description  variable 

-  union  of  one  or  more  regions 


Effect  descriptions  correspond  to  the  side-effects  of  ordinary  expressions, 
as  expressed  in  terms  of  the  allocating,  reading,  and  writing  of  locations  in 
certain  regions.  The  maxeif  of  zero  or  more  effect  descriptions  corresponds 
to  the  combination  of  the  corresponding  effects. 


Effect  = 


-  effect  descriptions  (e) 
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Econst 

Dvar 

(alloc  Region ) 
(read  Region ) 
(write  Region) 
(maxeff  Effect*) 


-  effect  constant 

-  description  variable 

-  allocate  in  a  region 

-  read  from  a  given  region 

-  write  to  a  given  region 

-  combine  zero  or  more  effects 


Type  descriptions  correspond  to  sets  of  values,  which  we  call  types.  For 
example,  the  type  constant  unit  corresponds  to  the  set  {#u}  and  the  type 
constant  bool  corresponds  to  the  set  {#t,#f}.  The  precise  meaning  of  “val¬ 
ues”  is  given  on  page  121. 


Type  =  -  type  descriptions  (r) 

Tconst  ~  type  constant 

Dvar  -  description  variable 

(subr  Effect  (Type)  Type)  -  ordinary  subroutines 
(poly  (Dvar  Kind)  Type)  -  polymorphic  subroutines 
(ref  Type  Region)  -  locations 

The  description  (subr  e  (ri)  r2)  is  a  generalization  of  the  type  rj— >r2  in 
the  typed  lambda-calculus.  It  corresponds  to  the  set  of  ordinary  subroutines 
that,  when  applied  to  a  value  in  ri,  cause  a  side-effect  of  at  most  e  and  either 
diverge  or  return  a  value  whose  type  is  a  subtype  of  r2 .  The  term  “subtype” 
is  defined  on  page  122. 

The  description  (poly  ( d  k)  t)  is  a  generalization  of  the  type  Vt.r  in  the 
second-order  typed  lambda-calculus.  It  corresponds  to  the  set  of  polymor¬ 
phic  expressions  that,  when  projected  onto  a  description  6  of  kind  «,  either 
diverge  or  return  a  value  whose  type  is  at  most  r[5/d],  without  causing  any 
side-effects.  The  post-fix  [S/d]  denotes  substitution  of  6  for  d,  where  bound 
variables  are  renamed  as  needed  to  avoid  capture. 

The  description  (ref  r  p)  is  a  generalization  of  the  type  ref  r  in  pro¬ 
gramming  languages  such  as  ML.  It  corresponds  to  the  set  of  locations  in 
the  region  p  that  are  intended  for  values  whose  type  is  a  subtype  of  r. 

The  grammar  for  descriptions  in  general  is  obtained  by  combining  the 
region,  effect,  and  type  descriptions. 
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Desc  = 


Region 

Effect 

Type 


-  descriptions  (5) 

-  region  descriptions 

-  effect  descriptions 

-  type  descriptions 


Ordinary  expressions  serve  to  express  programs  and  the  resulting  values. 
We  discuss  the  ordinary  expressions  below,  but  first  we  define  the  ordinary 
constants  and  variables. 


Unit  =  {#u} 

Bool  =  {#t,  *1} 

Var  =  {n,u,...} 


-  the  unit  type 

-  Boolean#  (b) 

-  ordinary  variables  (x) 


The  constants  of  the  language  are  #u,  #t,  and  #1. 


Const  = 


Unit 

Bool 


-  ordinary  constants  ( c ) 

-  the  unit  type 

-  the  Boolean# 


The  grammar  for  ordinary  expressions  in  general  is  given  below.  There 
are  three  general  classes  of  ordinary  expressions:  expressions  that  derive 
from  the  second-order  typed  lambda-calculus;  expressions  that  deal  with 
evaluation  order;  and  expressions  that  deal  with  side-effects.  The  first  class 
consists  of  constants  and  variables,  ordinary  abstraction  and  application,  and 
polymorphic  abstraction  and  projection.  The  second  class  consists  of  expres¬ 
sions  for  conditional  and  sequential  evaluation.  The  third  class  consists  of 
expressions  for  asserting  type  and  effect  and  for  the  allocating,  reading,  and 
writing  of  locations. 


exp  = 


Const 


-  ordinary  expressions  (e) 

-  ordinary  constants 


120 


B.2.  Free  Variables  and  Constants 


1+2 


Var 

(lambda  (Var  Type)  exp) 

( exp  exp) 

(plambda  (Dvar  Kind )  exp) 
(proj  exp  Desc) 

(if  exp  exp  exp) 

(begin  exp+) 

(the  Effect  Ty pe  exp) 

(new  Type  Region  exp) 

(get  exp) 

(set  exp  exp) 


-  ordinary  variables 

-  ordinary  abstraction 

-  ordinary  application 

-  polymorphic  abstraction 

-  polymorphic  application 

-  conditional  evaluation 

-  sequential  evaluation 

-  effect/type  assertion 

-  allocating  a  location 

-  reading  a  location 

-  writing  a  location 


1 

■' V 

■C-v 


Notice  that  new,  get,  and  set  are  special  forms  here  while  they  were 
polymorphic  subroutines  in  the  main  body  of  the  manual.  This  allows  ex¬ 
planation  of  semantics  involving  new,  get,  and  set  without  the  complexity 
of  projecting  them. 

Certain  ordinary  expressions,  such  as  applications,  represent  computa¬ 
tions ;  other  ordinary  expressions,  such  as  constants,  do  not  exhibit  any  com¬ 
putational  behavior,  and  represent  values. 

Definition.  An  ordinary  expression  is  a  value  iff  it  is  a  constant,  a 
lambda  expression,  or  a  plambda  expression.  We  use  Vai  to  denote  the  set 
of  values  and  v  to  denote  individual  values.  In  other  words, 


Val  = 


Const 

(lambda  (Var  Type)  exp) 
(plambda  (Dvar  Kind)  exp) 


-  values  (v) 

-  ordinary  constant 

-  ordinary  abstraction 

-  polymorphic  abstraction 
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B.2  Free  Variables  and  Constants 

Free  and  bound  variables  are  defined  as  in  the  second-order  typed  lambda- 
calculus;  in  particular,  lambda  binds  ordinary  variables,  and  plambda  and 
poly  bind  description  variables.  This  is  formalized  in  the  following  defini¬ 
tions. 
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Definition.  The  free  ordinary  variables  of  an  ordinary  expression  are 
given  by  the  function  FV  :  exp  — ►  PowerSet(  Var) . 

Definition.  The  free  description  variables  of  a  description  expression 
are  given  by  the  function  FIN  :  Desc  — »  PowerSet(Dvar). 

Definition.  The  free  description  variables  of  an  ordinary  expression  are 
given  by  the  function  FIN  :  exp  — »  PowerSet(Dvar). 

We  adopt  the  usual  notions  of  alpharrenaming  and  beta-substitution  for 
bound  variables.  We  use  the  notation  6\[8i/cC[,  e[<5/d]  and  ei[e2/a:]  to  indicate 
beta-substitution,  where  bound  variables  are  renamed  as  needed  to  avoid 
capture.  We  adopt  the  usual  definition  of  closed  descriptions  and  ordinary 
expressions: 

Definition.  A  description  8  is  closed  iff  it  has  no  free  description  vari¬ 
ables,  i.e.  iff  FIN {6)  =  4>. 

Definition.  An  ordinary  expression  e  is  closed  iff  it  has  no  free  ordinary 
variables  and  no  free  description  variables,  i.e.  iff  FV(e)  =  <f>  A  FIN (e)  =  <f>. 

It  is  convenient  to  define  the  free  region  constants  of  a  description, 
FRC {8),  and  of  an  ordinary  expression,  FRC[e).  Since  region  constants 
cannot  be  bound,  the  definition  of  FRC  and  FRO  is  trivial:  all  the  region 
constants  that  occur  in  a  description  or  ordinary  expression  are  free. 

Definition.  The  free  region  constants  of  a  description  are  given  by  the 
function  FRC  :  Desc  — »  PowerSet(Rconst). 

Definition.  The  free  region  constants  of  an  ordinary  expression  are 
given  by  the  function  FRC  :  exp  — *  PowerSet(Rcoast) . 

B.3  Description  Conversion  and  Inclusion 

In  this  section,  we  define  the  conversion  and  inclusion  relations  on  descrip¬ 
tions.  The  conversion  relation  (c*)  is  an  equivalence  relation  that  partitions 
Desc  into  sets  of  descriptions  that  correspond  to  the  same  underlying  sets 
of  locations,  effects,  or  values.  Two  descriptions  can  be  convertible  only  if 
they  have  the  same  kind. 

The  inclusion  relation  (C)  is  a  partial  order  that  relates  pairs  of  descrip¬ 
tions  that  correspond  to  sets  such  that  one  is  a  subset  of  the  other.  Thus, 
one  region  is  a  subregion  of  another  if  the  set  of  locations  corresponding  to 
the  former  is  a  subset  of  the  set  of  locations  corresponding  to  the  latter.  This 
rule  applies  to  effects  and  types  as  well.  Two  descriptions  can  be  related  only 
if  they  have  the  same  kind;  it  follows  that  the  description  inclusion  relation 
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is  simply  a  combination  of  the  independent  subregion,  subeffect,  and  sub- 
type  relations.  These  inclusion  relations  are  defined  below.  The  conversion 
relation  then  follows  from  the  definition  of  inclusion: 

~  O  (£j  C  62)  A  3  ^j) 

The  conversion  and  inclusion  relations  are  determined  completely  by  the 
correspondence  between  descriptions  and  sets  of  locations,  effects  or  values 
respectively. 

Region  Descriptions 

As  previously  mentioned,  a  region  description  corresponds  to  a  countably 
infinite  set  of  locations.  We  define  the  inclusion  relation  on  regions  to  corre¬ 
spond  to  set  inclusion  on  these  sets.  In  the  language  defined  in  this  appendix 
and  in  full  FX,  there  is  no  aliasing  between  region  constants  or  region  vari¬ 
ables.  As  a  result,  we  can  assume  that  individual  region  constants  and 
region  variables  correspond  to  disjoint  sets  of  locations.  This  leads  us  to  the 
definition  of  region  inclusion  given  below. 

Definition.  The  region  description  pi  is  included  in  the  region  descrip¬ 
tion  p2,  pi  C  pj,  iff  FRC(pi)  C  FRC(pi)  A  FDV(pi)  C  FDV{p2). 

Comment.  Since  every  region  description  is  built  up  out  of  region  con¬ 
stants  and  region  variables,  the  set  of  region  descriptions  modulo  conversion 
is  isomorphic  to  PowerSet[Rconst  U  Dvar),  the  set  of  all  possible  combina¬ 
tions  of  region  constants  and  region  variables.  It  follows  that  the  region 
descriptions  modulo  conversion  form  a  Boolean  lattice. 

Effect  Descriptions 

As  previously  mentioned,  an  effect  description  corresponds  to  a  set  of  alloc, 
read,  and  write  effects  on  certain  regions.  We  define  the  inclusion  relation 
on  effects  to  correspond  to  set  inclusion  on  these  sets  of  primitive  effects. 
Note  that  under  this  interpretation,  the  effect  constructors  alloc,  read,  and 
write  distribute  over  the  region  constructor  runion:  for  example,  the  effect 
description  (alloc  (runion  rj  r2))  corresponds  to  the  same  effect  as  the 
description  (maxefi  (alloc  ri)  (alloc  rj)).  This  leads  us  to  the  definition 
of  effect  inclusion  given  below. 

Definition.  The  inclusion  relation  C  on  effect  descriptions  is  the  par¬ 
tial  order  generated  by  the  inference  rules  given  below,  where  we  identify 
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descriptions  that  are  equal  modulo  the  distributive  laws.  We  say  that  e  is  a 
subeffect  of  e1  iff  e  C  e1. 


_ _ 

(alloc  p)  O  (alloc  p') 

(read  p)  C  (read  p') 

(write  p)  Q  (write  p') 

Ci  Q  c  for  all  1  <  *  <  n 

(m&xefi  £i...f„)  C  £ 

€  C  £<  for  some  1  <  t  <  n 
e  C  (aaxelt  ti . .  .<„) 

In  other  words,  the  effect  constructors  alloc,  read,  and  write  are  mono¬ 
tonic  with  respect  to  description  inclusion,  and  the  effect  constructor  aaxelf 
acts  as  the  n-ary  least  upper  bound  operation. 

Comment.  Since  every  effect  description  is  built  up  out  of  primitive 
effect  descriptions  (of  the  form  (alloc  p),  (read  p)  or  (write  p))  and  effect 
variables,  the  set  of  effect  descriptions  modulo  conversion  is  isomorphic  to 
PowerSet(({alloc,read,  write}  x  (Rconst  U  Dvar))  U  Dv ar),  the  set  of  all 
possible  combinations  of  primitive  effects  and  effect  variables.  It  follows  that 
the  effect  descriptions  modulo  conversion  form  a  Boolean  lattice. 

Type  Descriptions 

As  previously  mentioned,  a  type  description  corresponds  to  a  set  of  values. 
We  define  the  inclusion  relation  on  types  to  correspond  to  set  inclusion  on 
these  seta  of  values. 

Definition.  The  inclusion  relation  C  on  type  descriptions  is  the  partial 
order  generated  by  the  inference  rules  below,  where  we  identify  descriptions 
that  are  equal  modulo  the  distributive  laws  and  alpha-renaming.  We  say 
that  r  is  a  subtype  of  r'ilfrCr1, 

The  type  inclusion  inference  rule  for  the  type  constructor  subr  reflects 
the  fact  that  subr  is  monotonic  in  its  effect  and  return  type  components, 
but  anti-monotonic  in  its  parameter  type  component.  This  follows  from  its 
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interpretation  as  a  generalization  of  the  type  constructor  — »  in  the  typed 
lambda-calculus . 


fCt'  A  T\  □  r{  A  rj  C  r { 

(subr  f  (rx)  r2)  C  (subr  d  (r{)  r2) 

The  rule  for  the  type  constructor  poly  reflects  the  fact  that  poly  is 
monotonic  in  its  return  type  component 

r  C  r' 

(poly  (d  k)  r)  C  (poly  (d  k)  r') 

The  rule  for  the  type  constructor  ref  reflects  the  fact  that  ref  is  mono- 
tonic  in  its  region  component,  but  neither  monotonic  nor  anti-monotonic  in 
its  type  component.  As  for  the  region  component,  monotonicity  follows  from 
the  fact  that  the  inclusion  relation  on  region  descriptions  corresponds  to  set 
inclusion  on  the  underlying  seta  of  locations.  As  for  the  type  component, 
the  rule  reflects  the  fact  that  in  the  presence  of  side-effects,  neither  r  C  r' 
nor  r  3  r'  implies  (ref  r  p)  C  (ref  r'  p). 

p  C  p*  a  r  ~  r' 

(ref  r  p)  C  (ref  r'  p') 

To  understand  why  ref  is  not  monotonic  in  its  type  component,  consider 
this.  Computationally,  a  location  is  equivalent  to  a  pair  of  subroutines,  one 
for  reading  and  one  for  writing.  Thus,  the  type  (ref  r  p)  is  in  some  sense 
equivalent  to  a  tuple  of  two  types: 

(subr  (read  p)  (unit)  r) 
and 

(subr  (write  p)  (r)  unit) 

Since  r  appears  as  the  return  type  in  the  first  type,  (ref  r  p)  is  a  subtype  of 
(ref  r'  p)  only  if  r  C  r\  Yet,  since  r  appears  as  the  parameter  type  in  the 
second  type,  (ref  r  p)  is  a  subtype  of  (ref  r'  p)  only  if  r  □  r'.  It  follows 
that  (ref  r  p)  is  neither  monotonic  nor  anti-monotonic  in  r. 

Comment  The  type  descriptions  modulo  conversion  do  not  form  a  lat¬ 
tice,  because  the  set  is  not  closed  under  LI  and  n;  for  example,  the  type  de¬ 
scriptions  bool  and  (ref  bool  ri)  have  neither  an  upper  nor  a  lower  bound. 
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B.4  Kind,  Type,  and  Effect  Inference 

Every  well-formed  description  has  a  kind,  which  is  one  of  region,  effect 
or  type.  Similarly,  every  well-formed  ordinary  expression  has  both  a  type 
and  an  effect  description.  In  this  section  we  present  a  set  of  axioms  and 
inference  rules  for  determining  the  kind  of  a  description  and  the  type  and 
effect  descriptions  of  an  ordinary  expression. 

Kinds 

Since  a  description  may  have  free  description  variables,  the  kind  of  a  de¬ 
scription  is  defined  in  the  context  of  a  kind  assignment,  which  is  a  partial 
function  with  signature  Dvar  — ►  Kind  that  maps  description  variables  to 
their  kinds.  We  use  Kas  to  denote  the  set  of  kind  assignments  and  B  to 
denote  individual  kind  assignments.  We  use  the  notation  f[x  >-*  y]  to  denote 
the  function  similar  to  /  except  that  it  maps  x  to  y.  The  relation  has  kind, 
or  ::  ,  on  ( Desc  x  Kas)  x  Kind  gives  the  kind,  if  any,  of  a  tuple  consisting 
of  a  description  and  a  kind  assignment. 

Definition.  The  relation  has  kind  is  the  least  relation  consistent  with 
the  axioms  and  inference  rules  below.  The  axioms  state  that  every  region 
constant  has  kind  region,  every  type  constant  has  kind  type,  and  every 
description  variable  d  in  the  domain  of  B  has  kind  B[d). 

( r ,  B)  ::  region 

{t,  B)  ::  type 

(d,B)  ::  B{d) 

The  kind  inference  rule  for  region  descriptions  states  that  the  runion  of 
one  or  more  descriptions  of  kind  region  also  has  kind  region. 

{ Pi ,  B)  ::  region  for  all  1  <  i  <  n 
{(runion  pi...pn),B)  ::  region 

There  are  two  kind  inference  rules  for  effect  descriptions.  The  first  rule 
states  that  if  p  has  kind  region,  then  the  effect  descriptions  (alloc  p), 
(read  p)  and  (write  p)  all  have  kind  effect. 


(p,  B)  ::  region 


((alloc  p),  B)  :: 

effect 

((read  p),  B)  :: 

effect 

((write  p),  B)  :: 

effect 

126 


S'i'J 

M 


,y| 

t'L  _ 
««S*1 

A 

>1 


<’V*V 

M 


B.4.  Kind,  Type,  and  Effect  Inference 


The  second  rule  states  that  the  maxef f  of  zero  or  more  descriptions  of  kind 
effect  also  has  kind  effect.  In  particular,  the  effect  description  (maxeff) 
or  pure  has  kind  effect. 

( ti,B )  ::  effect  for  all  1  <  t  <  n 
((maxeff  ei  ...en),B)  ::  effect 

Finally,  there  are  three  kind  inference  rules  for  type  descriptions.  The 
first  two  rules  are  direct  adaptations  of  the  corresponding  rules  in  the  second- 
order  typed  lambda-calculus,  changed  only  to  handle  the  effect  component 
of  the  subr  and  poly  type  descriptions. 


(t,B)  ii 

effect 

ii 

type 

(rj.fl)  :: 

type 

{(subr  e  (n)  r2),  B)  ::  type 


(r,  B[d  >-*  #c|)  ::  type 

(e,  B[d  •-»  #cj)  s:  effect 
((poly  (die)  r),B)  it  type 

The  rule  for  ref  type  descriptions  simply  states  that  if  p  has  kind  ref 
and  r  has  kind  type,  then  (ref  r  p)  has  kind  type. 

(p,  B )  ::  region 

(r,  B)  ::  type 

((ref  r  p),B)  ::  type 

Definition.  A  tuple  (6,  B)  is  well-formed,  W?((6,  B )),  iff  it  has  a  kind, 
i.e.  iff  (6,  B)  ::  k  for  some  kind  k. 

Definition.  A  closed  description  6  is  well- formed,  W?(6),  iff  it  has  a 
kind  under  the  empty  kind  assignment,  i.e.  iff  ( 6,<f> )  ::  ic  for  some  ic.  If  S 
is  closed  and  well-formed  and  ( 6,<j> )  ::  k,  we  write  6  ::  ic  and  say  that  6  has 
kind  ic. 

Fact.  If  the  tuple  ( 6 ,  B)  is  well-formed,  then  its  kind  is  unique;  in  other 
words,  if  (6,  B)  ::  ici  and  (6,  B)  ::  ic2  then  =  ic2.  It  follows  that  the 
relation  has  kind  is  a  partial  function. 
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The  Types  and  Effects  of  Expressions 

In  this  section  we  give  a  set  of  axioms  and  rules  for  determining  the  type 
and  effect  description  of  an  ordinary  expression.  Because  an  ordinary  ex¬ 
pression  may  have  free  ordinary  and  description  variables,  its  type  and  effect 
description  are  defined  in  the  context  of  both  a  kind  assignment  and  a  type 
assignment,  which  is  a  partial  function  with  signature  Var  — ►  Type  that 
maps  ordinary  variables  to  their  type  descriptions.  We  use  Tas  to  denote 
the  set  of  type  assignments  and  A  to  denote  individual  type  assignments. 

The  relation  has  type,  or  :  ,  on  ( exp  x  Tas  x  Kas)  x  Type  gives  the  type 
description,  if  any,  of  a  tuple  (e,  A,  B)  consisting  of  an  ordinary  expression, 
a  t>  pe  assignment,  and  a  kind  assignment.  Likewise,  the  relation  has  effect, 
or  !  ,  on  (exp  x  Tas  x  Kas)  x  Effect  gives  the  (unmasked)  effect  description, 
if  any,  of  such  a  tuple.  Effect  masking  is  described  below. 

Definition.  The  relations  has  type  and  has  effect  are  the  least  relations 
consistent  with  the  axioms  and  inference  rules  below. 

The  type  axioms,  below,  state  that  #u  has  type  unit;  the  Booleans  #t 
and  #1  have  type  bool;  and  every  ordinary  variable  x  in  the  domain  of  A 
has  type  A(x). 

(#u,  A,  B)  :  unit 

((,  A,  B)  :  bool 

(x,  A,  B)  :  A(x) 

The  effect  axioms,  below,  state  that  every  ordinary  constant  or  variable 
and  every  abstraction  expression,  whether  ordinary  or  polymorphic,  has  ef¬ 
fect  pure,  regardless  of  the  type  or  kind  assignment. 

( v ,  A,  B)  !  pure 
(z,  A,  B)  1  pure 

The  type  inference  rule  for  ordinary  abstraction  is  a  generalization  of  the 
corresponding  rule  in  the  typed  lambda-calculus.  The  main  difference  is  that 
the  effect  description  of  the  body  of  the  lambda  expression  is  incorporated 
into  the  type  description  of  the  expression  itself.  This  reflects  the  fact  that 
the  side-effects  (if  any)  of  the  body  do  not  take  place  when  the  lambda 
expression  is  evaluated,  but  when  the  subroutine  is  applied.  Note  that  the 
effect  description  of  a  lambda  expression  is  always  pure,  by  the  corresponding 
effect  axiom. 

(e,  A[x  »-»  nj.fl)  !  e 
_ (e,  A(z>->  :  r2 _ 

((lambda  (x  rj)  e),  A,  B)  :  (subr  c  (rj)  rj) 
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The  rule  for  application  is  a  generalization  of  the  corresponding  rule  in 
the  typed  lambda-calculus.  The  main  difference  is  that  the  effect  descrip¬ 
tion  embedded  in  the  type  of  the  subroutine  is  incorporated  into  the  effect 
description  of  the  application  as  a  whole.  This  reflects  the  fact  that  the  side- 
effects  (if  any)  of  the  body  of  the  subroutine  take  place  when  the  subroutine 
is  applied.  Note  that  the  type  description  of  the  actual  parameter  need  not 
match  that  of  the  formal  parameter  exactly,  but  must  be  included  in  it. 

(eltA,B)  :  (subr  e  (n)  r2) 

(e2,A,B)  :  r  A  r  C  n 

(ei  ,A,B)  1  ci 

{e2,A,B)  1  e3 _ 

((ei  «2 ),A,B)  :  r2 

((<i  «z),  -A.  B)  !  (maxell  ex  £2  e) 


The  rule  for  polymorphic  abstraction  is  a  generalization  of  the  corre¬ 
sponding  rule  in  the  second-order  typed  lambda-calculus.  The  main  differ¬ 
ence  is  that  the  effect  description  of  the  body  of  the  plambda  expression 
must  be  pure.  Note  that  this  rule  ensures  that  the  free  description  variables 
of  the  types  of  the  free  variables  of  the  body  are  not  captured  by  the  bound 
description  variable.  Also,  the  effect  description  of  a  plambda  expression  is 
always  pure,  by  the  corresponding  effect  axiom. 

(e,  A,  B[d  ■-*  «])  :  r 

(e,  A,  B[d  *])  !  pure 

z  g  FV(e)  =>  d  j  FDV{A{x)) 

((plambda  (d  k)  e),  A,  B )  :  (poly  (d  k)  r) 

The  rule  for  projection  is  a  generalization  of  the  corresponding  rule  in 
the  second-order  typed  lambda-calculus.  This  rule  also  enforces  the  anti¬ 
aliasing  provision  of  the  language:  it  ensures  that  if  the  actual  parameter  is 
a  region  description,  then  the  expression  as  a  whole  is  not  well-typed  unless 
the  actual  parameter  is  disjoint  from  the  free  region  variables  and  region 
constants  of  the  type  of  the  operator.  This  ensures  that  the  application  does 
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not  create  aliasing  between  region  constants  and/or  region  variables. 


(e,  A,  B) 
(e,A,  B) 
(6,B) 

k  =  region 


r  =  (poly  ( d  k)  t') 
e 

K 

j  FRC(t)  n  FRC(S)  =  <f> 
\FDV{T)nFDV{6)  =  <t> 


((proj  e6),A,B)  :  r'[S/d\ 
((proj  e  5),  A,B)  !  e 


The  rule  for  conditional  expressions  ensures  that  the  first  subexpression 
has  type  description  bool,  and  that  the  remaining  two  subexpressions  have 
type  descriptions  whose  maximum  exists.  When  this  is  the  case,  the  type 
description  of  the  if  expression  is  this  maximum,  and  its  effect  description  is 
the  maximum  bound  of  the  effect  descriptions  of  its  subexpressions,  reflecting 
the  fact  that  evaluating  an  if  expression  involves  evaluating  some  subset  of 
its  subexpressions. 


(et,A,  B)  J  bool  (ei,A,B)  I  c\ 

(eJ,  A,  B)  :  r2  (e2,A,B)  !  e2 

(«s,  A,  B)  :  r3  <e3,  A,  B )  I  cs 

r2  U  r3  =  r  A  (r  =  r2  V  r  =  r3) 
((if  e2  e3),  A,  B)  :  r 
((if  ei  e2  e3),A,B)  !  (aaxeff  ex  e2  e3) 


The  rule  for  sequencing  ordinary  expressions  is  remarkably  simple:  pro¬ 
vided  that  each  subexpression  has  a  type  and  effect  description,  the  type 
description  of  a  begin  expression  is  the  same  as  that  of  the  last  subex¬ 
pression,  and  the  effect  description  is  the  least  upper  bound  of  the  effect 
descriptions  of  the  subexpressions. 

{ei,  A,  B)  :  r,  for  all  1  <  i  <  n 
(e,  ,  A,  B)  !  e,  for  all  1  <  i  <  n 
((begin  ex . .  .e„),i4,  B)  :  r„ 

((begin  e\  . .  .e„),  A,  B)  !  (maxeff  ej  . . .  e„) 

The  rule  for  effect/type  assertion  allows  an  expression  of  some  particular 
effect  and  type  to  be  regarded  as  though  it  had  a  larger  effect  and  type. 
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(t',  B)  ::  type 

{d,B)  ::  effect 

(e,A,B)  :  r 

(e,  A,  B)  t  e 

r  C  r'  A  tCe* 

{(the  d  t1  e),  A,  B)  :  t' 

{(the  d  r'  e),  A,  B)  !  d 

The  remaining  three  rules  deal  with  the  expressions  for  allocating,  read¬ 
ing,  and  writing  locations.  The  rule  for  the  new  expression  can  be  read  as 
follows:  provided  that  p  has  kind  region,  r  has  kind  type,  and  e  has  a 
type  and  effect  description,  and  provided  that  the  type  description  of  e  is 
included  in  r,  the  type  description  of  the  expression  as  a  whole  is  (ref  r  p), 
and  the  effect  description  of  the  expression  is  the  least  upper  bound  of  the 
effect  description  of  e  and  the  primitive  effect  description  (alloc  p). 

{p,  B )  ::  region 

(r,  B)  :s  type 

(e,  A,B)  :  r'  A  r'  Q  t 

_ (e,  A,  B)  1  € _ 

((new  r  p  e),  A,  B )  :  (ref  r  p) 

((new  t  p  e),A,  B)  1  (maxeff  e  (alloc  p)) 

The  rule  for  the  get  expression  can  be  read  as  follows:  if  the  type  de¬ 
scription  of  e  is  (ref  r  p),  then  the  type  description  of  the  expression  as  a 
whole  is  r,  and  its  effect  description  is  the  least  upper  bound  of  the  effect 
description  of  e  and  the  primitive  effect  description  (read  p). 

(e,  A,  B)  :  (ref  r  p) 

_ (e,A,B)  1  e _ 

((g«t  e),  A,  B)  :  r 

{(get  e),  A,  B)  !  (maxeff  e  (read  p)) 

The  rule  for  the  set  expression  can  be  read  as  follows:  provided  that 
the  type  description  of  a  is  (ref  r  p)  such  that  the  type  description  of  e2  is 

included  in  r,  the  type  description  of  the  expression  as  a  whole  is  unit,  and 

its  effect  description  is  the  least  upper  bound  of  the  effect  descriptions  of  e\ 
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and  e2  and  the  primitive  effect  description  (write  p). 

(ei,A,B)  :  (ref  r  p) 

(e2,A,B)  :  r*  A  r'  C  r 

(ei,A,  B)  !  £j 

_ (ci,A,B)  1  f2 _ 

((set  t\  e2 ),A,B)  :  unit 

{(set  e\  e2),A,B)  I  (maxeff  ex  f2  (write  p)) 

Definition.  A  tuple  (e,  A,  B)  is  well-formed,  W?((e,  A,  B)),  iff  it  has  a 
type  description,  i.e.  iff  (e,  A,B)  :  r  for  some  r. 

Definition.  A  dosed  expression  e  is  well-formed,  W?(e),  iff  it  has  a  type 
description  under  the  empty  type  and  kind  assignments,  i.e.  iff  (e,<f>,<f>)  :  r 
for  some  r.  If  e  is  closed  and  well-formed  and  (e,  <f>,  <f>)  :  r,  we  write  e  :  r  and 
say  that  e  has  type  r;  similarly,  if  e  is  closed  and  well-formed  and  (e,  <f>,  <f>)  !  e, 
we  will  write  e  !  f  and  say  that  e  has  effect  f. 

Fact.  Every  well-formed  tuple  has  an  effect  description;  in  other  words, 
if  (e,  A,  B)  s  r  for  some  r  then  (e,  A,  B)  !  e  for  some  e. 

Fact.  If  the  tuple  (e,  A,  B)  is  well-formed,  then  its  type  and  effect 
descriptions  are  themselves  well-formed  and  of  kind  type  and  effect  re¬ 
spectively,  provided  that  the  type  descriptions  in  A  of  the  free  variables 
of  e  are  well-formed.  In  other  words,  if  (A(i),B)  is  well-formed  for  each 
x  €  FV(e),  then  if  (e,  A,  fl)  :  r  and  (e,  A,  B)  1  t  then  (r,  B)  ::  type  and 
(e,  B)  ::  effect. 

Fact.  If  the  tuple  (e,A,B)  is  well-formed,  then  its  type  and  effect  de¬ 
scriptions  are  unique  modulo  conversion;  in  other  words,  if  (e,  A,  B)  :  t\  and 
(e,  A,  B)  :  r2  then  ri  ~  r2,  and  likewise  if  (e,A,B)  !  ti  and  (e,  A,  B)  !  c2 
then  £i  ~  e2.  It  follows  that  the  relations  has  type  and  has  effect  are  partial 
functions  (modulo  description  conversion). 

Effect  Masking 

Effects  that  are  not  observable  outside  of  a  given  expression  can  be  masked 
by  the  type  and  effect  system.  To  this  end,  all  expressions  are  subjected  to 
effect  masking  according  to  the  following  rule: 

If  the  expression  has  effects  on  some  region  identifier  d,  and  d 
does  not  appear  free  in  the  type  of  any  free  variable  of  the  expres¬ 
sion,  then  any  read  or  write  effect  on  d  is  masked;  furthermore, 
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if  d  does  not  appear  free  in  the  type  of  the  expression,  then  any 
alloc  effect  on  d  is  masked  too. 

In  order  to  define  effect  masking  formally,  we  introduce  the  pseudo-region 
o.  Conceptually,  o  corresponds  to  an  empty  region,  i.e.  a  region  to  which 
no  locations  belong.  Thus,  (runion.  o  p )  is  convertible  with  p  (for  all  p), 
and  the  effects  (alloc  o),  (read  o)  and  (write  o)  are  convertible  with  pure. 
The  pseudo-region  o  can  be  regarded  as  the  bottom  of  the  region  lattice.  We 
can  now  give  the  formal  effect  masking  inference  rules: 


(e,A,B)  : 

(e,A,B)  ! 

(d,B)  : 

x  €  FV(e)  =* 
d  9 


(e,A,B) 


region 

d#FV(A(x)) 

FV(r) 


!  t[o/d] 


8 


(e,  A,  B)  :  r 

(',A,B )  !  c 

(d,B)  ::  region 

i  €  FV{e)  =>  d$  FV(A(x)) 


( e,A,B )  !  (naxeil  e[o/d]  (alloc  d)) 

Due  to  effect  masking,  an  expression  may  have  many  effects:  one  that  has  not 
benefited  from  effect  masking,  one  in  which  nothing  remains  to  be  masked, 
and  any  number  that  are  somewhere  in  between.  To  deal  with  effect  mask¬ 
ing,  any  formula  of  the  form  (e,  A,  B)  !  e  in  a  premise  of  a  type  and  effect 
inference  rule  must  be  interpreted  as  meaning  that  e  is  the  least  effect  of 
( e,A,B ).  With  this  interpretation,  every  well-formed  tuple  ( e,A,B )  has  a 
type  description  and  a  least  effect  description  that  are  unique  modulo  con¬ 
version. 

B.5  Standard  Semantics 

The  standard  semantics  of  the  language  are  based  on  the  standard  rewrite 
rules  for  the  second-order  typed  lambda-calculus;  in  particular,  the  seman¬ 
tics  of  application  as  well  as  projection  are  expressed  in  terms  of  beta- 
substitution.  Side-effects  are  modeled  using  a  store  that  maps  locations 
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to  values.  To  avoid  the  complications  that  arise  when  a  computation  runs 
out  of  unused  locations,  we  define  a  store  to  be  a  finite  function  with  signa¬ 
ture  Loc  — ♦  VaJ  that  maps  locations  to  values.  Since  the  number  of  locations 
is  infinite  and  every  finite  computation  allocates  only  a  finite  number  of  lo¬ 
cations,  this  definition  ensures  that  a  computation  never  runs  out  of  unused 
locations.  We  use  Store  to  denote  the  ret  of  stores  and  o  to  denote  individual 
stores. 

Because  of  side-effects,  the  order  of  subexpression  evaluation  is  crucial  to 
the  semantics  of  the  language.  As  a  result,  the  rewrite  rules  are  directional 
—  hence,  from  now  on,  we  use  the  term  reduction  rather  than  rewriting. 

To  avoid  over-specification,  we  have  defined  the  standard  semantics  so 
that  new  locations,  when  needed,  are  chosen  nondeterministically.  This  gives 
the  language  implementation  a  great  deal  of  flexibility,  which  is  essential  to 
permit  such  optimizations  as  code  motion,  common  subexpression  elimina¬ 
tion,  and  dead  code  elimination. 

Locations 

Before  we  can  describe  the  semantics,  we  must  define  what  we  mean  by 
locations.  Formally,  locations  are  a  countably  infinite  set  of  constants: 


Loc  ~  {ii,h, . . .  }  -  locations  (/) 


Const  =  . . .  -  ordinary  constants  (c) 

Loc  -  the  locations 

A  location  can  be  tagged  with  a  region  description  and  a  type  description. 
The  region  tag  of  a  location  indicates  to  what  region  the  location  belongs, 
and  the  type  tag  of  a  location  indicates  what  types  of  values  the  location  may 
contain.  Specifically,  a  location  tagged  with  a  region  description  p  belongs 
to  the  region  p,  and  a  location  tagged  with  a  type  description  r  may  only 
contain  values  whose  type  is  a  subtype  of  r.  These  descriptions  ought  to  be 
closed ;  tags  that  contain  free  description  variables  are  meaningless. 

We  write  R(l )  for  the  region  tag  of  the  location  /  and  T(l)  for  its  type 
tag.  Moreover,  we  write  lp  r  to  indicate  that  R(1PiT)  =  p  and  T(lP:T)  =  r. 
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Every  closed  region  description  p  corresponds  to  a  nonempty  set  of  region 
constants,  namely  FRC(p).  If  p  is  a  region  constant,  then  the  location  lfiiT 
belongs  to  the  region  corresponding  to  that  region  constant.  If  p  is  a  runion 
of  several  region  constants,  then  the  location  lPiT  belongs  to  the  union  of  the 
corresponding  regions.  This  situation  reflects  either  uncertainty  or  indiffer¬ 
ence  about  the  region  constant  to  which  the  location  actually  belongs. 

It  is  convenient  to  define  the  free  locations  of  an  ordinary  expression, 
FL(e).  Since  locations  are  constants,  the  definition  of  FL  is  trivial:  all  the 
locations  that  occur  in  an  ordinary  expression  are  free. 

Definition.  The  free  locations  of  an  ordinary  expression  are  given  by 
the  function  FL  :  exp  — *  PowerSet(Loc) . 

Since  locations  are  constants  and  therefore  ordinary  expressions,  we  must 
define  their  free  ordinary  and  description  variables,  their  free  region  con¬ 
stants,  their  types,  and  their  effects.  The  first  few  are  easy:  since  locations 
are  constants,  they  have  neither  free  ordinary  variables  nor  free  description 
variables.  However,  because  of  its  region  and  type  tag,  a  location  may  have 
free  region  constants: 


FRC{1PiT)  =  FRC(p)  U  FRC(r) 

Because  locations  are  constants,  their  effect  is  pure.  Finally,  the  type  of  a 
location  is  a  ref  type  whose  region  and  type  parameters  are  equal  to  the 
region  and  type  tags  of  the  location: 


(le.r,  A,  B)  t  (ref  r  p) 


Stores  and  States 

The  state  of  a  computation  consists  of  two  components:  an  ordinary  expres¬ 
sion,  which  indicates  the  computation  that  remains  to  be  performed,  and  a 
store,  which  maps  locations  to  values. 

Definition.  A  store  is  a  finite  function  o  :  hoc  —*  Val  that  maps  loca¬ 
tions  to  values.  We  use  Store  to  denote  the  set  of  stores  and  <r  to  denote 
individual  stores. 

Definition.  A  state  is  a  tuple  (e,<7)  6  ( exp  x  Store).  We  use  State  to 
denote  the  set  of  states  and  6  to  denote  individual  states. 
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Reduction 

The  reduction  relation  ==>  on  (State  x  State)  is  defined  by  a  set  of  reduction 
axioms  and  a  set  of  reduction  inference  rules.  The  reduction  axioms  show 
how  to  reduce  an  ordinary  expression  when  certain  of  its  subexpressions  have 
been  reduced  to  values;  the  reduction  inference  rules  show  how  to  reduce 
an  ordinary  expression  to  which  none  of  the  reduction  axioms  applies  by 
reducing  one  of  its  subexpressions. 

A  value  cannot  be  reduced;  in  other  words,  for  all  v  and  a  there  is  no 
9  such  that  { v,a )  =>  0.  We  make  extensive  use  of  this  fact  to  ensure  that 
subexpressions  are  evaluated  in  left-to-right  applicative  order.  For  example, 
the  reduction  axiom  for  ordinary  application  (shown  below)  is  applicable 
only  when  the  operator  is  a  lambda  expression,  which  is  a  value,  and  the 
operand  is  a  value  as  well.  This  technique  is  used  throughout  to  keep  the 
reduction  axioms  and  inference  rules  from  being  invoked  prematurely. 

The  first  two  axioms,  which  deal  with  application  and  projection,  are 
adapted  directly  from  the  second-order  typed  lambda  calculus.  Note  that 
the  store  is  not  affected. 

(((lambda  (x  r)  e)  v),<r)  (e[v/x],o) 

((proj  (plambda  ( d  k)  e)  6), a)  ==>  ( e[6/d\,a ) 

The  axiom  for  ordinary  application  may  entail  duplication  of  the  actual 
parameter.  This  does  not  cause  any  problems,  despite  the  possibility  of 
side-effects,  because  the  actual  parameter  is  a  value,  which  cannot  be  further 
reduced. 

The  next  set  of  axioms,  which  deal  with  conditional  and  sequential  eval¬ 
uation,  should  be  more  or  less  self-explanatory. 

((if  #t  ei  es),a)  =>  (ej,<r) 

((if  #f  ej  ei),<r)  =>  (es,<r) 

((begin  v),<r)  =>•  (v,o) 

((begin  v  ei ..  .e„),<r)  ((begin  ei ... e„),<r)  (n  >  0) 

((the  e  r  v),<r)  (v,o) 

The  remaining  axioms  deal  with  the  allocating,  reading,  and  writing  of 
locations.  In  what  follows,  we  use  the  notation  c[l  *-*  v]  to  denote  the 
store  that  is  identical  to  <r  except  that  it  maps  l  to  v,  while  simultaneously 
expressing  the  fact  that  l  is  not  bound  in  a.  We  use  the  symbol  ”  to  denote 
an  undefined  value,  so  that  <x [/  • — ►  -]  denotes  the  store  a  while  expressing 
the  fact  that  l  is  not  bound  in  a. 
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The  axiom  for  the  new  expression  can  be  read  as  follows.  To  reduce  the 
expression  (new  r  p  v),  choose  any  location  l  of  type  r  in  the  region  p  that 
is  not  bound  in  the  store.  By  the  definition  of  a  store,  such  a  location  exists 
iff  r  and  p  are  closed.  Once  a  suitable  location  /  has  been  chosen,  simply 
bind  1  to  v  in  the  store,  and  replace  the  expression  by  the  value  /. 

((new  r  p  «/),*[/,,,  •-»  -]>  (/,*[/  v]> 

This  axiom  represents  a  non-deterministic  reduction:  unlike  the  other 
axioms,  this  axiom  permits  a  state  to  reduce  (in  one  step)  to  a  countably 
infinite  number  of  states,  differing  only  in  their  choice  of  the  new  location. 
The  course  of  a  computation  is  not  affected  by  the  choice  of  new  locations. 

To  reduce  the  expression  (get  /),  where  l  is  bound  to  v  in  the  store, 
simply  replace  the  expression  by  the  value  v. 

((get  l),  tr[l  •-»  v])  ^  (v,  <r[l  ~  v]) 

To  reduce  the  expression  (set  /  v),  where  l  is  bound  in  the  store,  simply 
bind  /  to  v  in  the  store  and  replace  the  expression  by  the  value  #u. 

((set  1  v),o\l  *-*■  v'])  ==>•  (#u,<r[f  •->  v]) 

This  concludes  the  set  of  reduction  axioms.  Note  that  each  of  these 
axioms  is  applicable  only  when  certain  subexpressions  of  the  outermost  or¬ 
dinary  expression  are  values.  The  reduction  inference  rules,  which  are  given 
below,  show  how  to  reduce  an  ordinary  expression  to  which  none  of  the 
reduction  axioms  applies  by  reducing  one  of  its  subexpressions.  There  are 
quite  a  few  of  these  rules:  two  for  application  (one  for  the  operator  subex¬ 
pression  and  one  for  the  operand) ,  one  for  projection  (since  the  operand  is  a 
description,  which  does  not  need  to  be  reduced),  one  each  for  if,  begin,  and 
the  one  each  for  new  and  get,  and  two  for  set.  The  rules  are  all  structured 
so  that  subexpressions  are  evaluated  in  left-to-right,  applicative  order. 

{cx,g)=g>  (c^g*) 

((«i  ((e'l  ej),*') 


(e8,g)^  (c*;,^) 

<(vi  e2),<r)^>{{vx  e's),a') 
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_ (e,a)£2>(  e1,*') _ 

{(proj  c  5),a)^>  ((proj  e'  6 ),*') 

_ (el>g)  =»  (Cl,gl) _ 

((if  ei  e2  c3),ff)  ==►  ((if  ex  ej  es),<7') 

_ (eu*)^Wl,ol) _ 

((begin  ex  e2  . . .  en),  <*)  ^  ((begin  e\  e2 . . .  en),  a') 

_ (e,a)^  (e’ytr') _ 

((the  c  r  e),<r)=^  ((the  £  r  e^o') 

_ (g.ff)^-  (cV) _ 

((new  r  p  e),<r)  ((new  r  p  e'l.o') 

(e,g)=^.  (e*,^) 

((get  e),<r)^>  ((get  £*)»*'> 

_ (el>g)  Wl)*') _ 

((■et  ex  e2),<r)  ((eet  e\  e2),<r') 

(e3,a)^(e'2,<rl) 

((set  v  e2),<r)  =>  ((set  v  e j),<y') 

Stuck  States 

Definition.  A  state  (e,<r)  is  stuck  iff  e  is  not  a  value  and  the  state  cannot 
be  reduced,  t.e.  iff  e  $  Val  and  there  is  no  0  such  that  (c,o)  =>  0. 

A  comparison  of  the  grammar  of  ordinary  expressions  on  the  one  hand 
and  the  reduction  axioms  on  the  other  hand  yields  a  list  of  the  different 
sorts  of  stuck  states.  If  the  state  (e,<r)  is  stuck,  then  either  e  contains  a 
subexpression  that  is  stuck,  or  t  is  one  of  the  following: 
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-  a  variable 

-  (t>i  v3)  where  vj  is  not  an  ordinary  subroutine 

-  (proj  v  6)  where  v  is  not  a  polymorphic  value 

-  (if  v  ej  eg)  where  v  is  not  a  Boolean 

-  (new  r  p  v)  where  p  and  r  are  not  closed  and  of  kind  region  and  type 
respectively 

-  (get  v)  where  v  is  not  a  location 

-  (get  /)  where  l  is  not  bound  in  the  store 

-  (set  t>i  vj)  where  vi  is  not  a  location 

-  (set  /  v)  where  l  is  not  bound  in  the  store 

These  expressions  can  be  divided  into  various  categories:  attempts  to  use 
undeclared  variables,  attempts  to  use  uninitialized  locations,  type  errors,  and 
kind  errors. 

Fact.  If  the  state  (e, a)  is  stuck,  then  e  must  either  be  ill-formed  or 
contain  some  location  whose  contents  is  either  undefined  or  of  the  wrong 
type. 

In  the  next  section,  we  show  that  reduction  of  a  well-formed  state  never 
gets  stuck.  In  particular,  this  implies  that  type  checking  prevents  run-time 
type  errors  and  attempts  to  use  uninitialized  locations. 

B.6  Types  Revisited 

In  this  section  we  present  several  properties  of  the  language  that  have  to 
do  with  types.  We  begin  by  generalizing  the  notion  of  well-formed  ordinary 
expression  to  that  of  a  well-formed  state.  We  can  then  verify  that  a  well- 
formed  state  is  not  stuck.  Moreover,  we  can  prove  that  reduction  of  a  well- 
formed  state  yields  another  well-formed  state  whose  type  and  effect  are  at 
most  those  of  the  original  state.  Finally,  we  show  that  reduction  of  a  well- 
formed  state  never  gets  stuck.  The  results  of  this  section  do  not  deal  with 
effect  masking. 
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Type  Soundness 

In  this  section  we  prove  that  reduction  of  a  well-formed  state  yields  another 
well-formed  state  and  preserves  or  decreases  the  type  and  effect  descriptions 
of  the  state.  As  an  intermediate  step,  we  introduce  the  notion  of  a  well- 
formed  store.  Informally,  a  store  is  well-formed  iff  all  the  values  in  the 
store  are  well-formed  and  are  of  the  right  type.  More  formally,  we  have  the 
following  definitions. 

Definition.  A  store  is  well-formed,  W7(o),  iff  every  value  in  the  store 
is  well-formed  and  has  a  type  description  that  is  included  in  the  type  of  its 
location.  In  other  words, 

Wf(o')  o  (<r =  t;  =>  tiir’Ar'Cr) 

We  also  introduce  the  notion  of  a  consistent  state.  Informally,  a  state  is 
consistent  iff  all  the  locations  that  occur  in  the  state  are  bound  in  its  store 
component. 

Definition.  A  location  1  occurs  in  a  store  o  iff  either  o(l)  —  v  for  some 
v,  or  l  occurs  in  a  value  <r(/')  for  some  l'.  The  locations  that  occur  in  a  store 
are  given  by  the  function  FL,tort,  which  is  formally  defined  below. 

FL«ort(c)=  U  {{l}uFL(o(l))) 

J€Dom*j  n(<r) 

Definition.  A  location  l  occurs  in  a  state  (e,<r)  iff  it  occurs  in  the 
expression  component  e  or  the  store  component  <r.  The  locations  that  occur 
in  a  state  are  given  by  the  function  FLtt*u ,  which  is  formally  defined  below. 

FL.taU((c,  a))  =  FL(e)  U  FLtiort{o) 

Definition.  A  state  is  consistent ,  Cons((e,tr)),  iff  every  location  that 
occurs  in  the  state  is  bound  in  the  store,  i.e.  iff  /  €  FL((e,o))  implies  that 
o(l)  =  v  for  some  v. 

We  can  now  define  what  constitutes  a  well-formed  state. 

Definition.  A  state  {e,a)  is  well-formed ,  W7((e,cr)),  iff  it  is  consistent 
and  e  and  a  are  both  well-formed.  In  other  words, 

W((e,<r))  Cons((e,<7-))  A  WT(e)  A 
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If  { e,a )  is  well-formed  and  e  :  r,  we  write  (e,<r)  :  r  and  say  that  ( e,cr ) 
has  type  r;  similarly,  if  (e,a)  is  well-formed  and  e  !  t,  we  write  (e,  a)  !  c  and 
say  that  ( e ,  a)  has  effect  e. 

Since  a  program,  by  definition,  contains  no  locations,  the  state  (e,  <f> )  is 
well-formed  for  any  well-formed  program  e. 

We  can  now  express  the  type  soundness  claim.  It  is  a  generalization  of  the 
type  soundness  theorem  (or  subject  reduction  lemma)  of  the  second-order 
typed  lambda-calculus,  which  states  that  reduction  of  a  well-typed  ordinary 
expression  yields  another  well- typed  ordinary  expression  of  the  same  type. 

The  claim  presented  here  is  more  general  than  the  type  soundness  theo¬ 
rem  of  the  lambda-calculus  in  three  respects:  side-effects,  description  inclu¬ 
sion,  and  effect  descriptions.  To  deal  with  side-effects,  the  claim  has  been 
generalized  from  ordinary  expressions  to  states.  To  deal  with  description  in¬ 
clusion,  the  claim  has  been  relaxed  so  that  the  reduction  of  a  state  of  type  r 
may  yield  a  state  of  any  type  r'  Cl  r.  Finally,  to  deal  with  effect  descriptions, 
the  following  claim  about  effect  descriptions  has  been  added:  the  reduction 
of  a  state  with  effect  c  must  yield  a  state  of  any  effect  d  C  e. 

Claim:  (Type  Soundness)  Reduction  of  a  well-formed  state  yields  an¬ 
other  well-formed  state,  preserves  or  decreases  the  type  and  effect  descrip¬ 
tions  of  the  state,  and  preserves  or  increases  the  set  of  locations  bound  in 
the  store. 


wr((e',<r')) 

e  :  r  e'  :  r'  where  r'  C  r 

c  !  e  e'  !  e1  where  t'Ce 

(e>  <0  =>■  (**)  &')  Dom&info1)  D  Dom*in(<T) 

Lemma:  A  well-formed  state  is  not  stuck. 

Corollary:  (Static  Typing)  Reduction  of  a  well-formed  state  never  gets 
stuck;  in  particular,  reduction  of  a  well-formed  state  never  encounters  a  type 
error,  a  kind  error,  or  an  uninitialized  location. 


B.7  Effects  Revisited 

In  this  section  we  present  several  properties  of  the  language  that  have  to 
do  with  effects.  The  main  property  we  show  is  that  the  actual  side-effect 
of  reducing  a  well-formed  state  is  equal  to  at  most  the  syntactic  side-effect 
of  the  original  state.  This  property  forms  the  basis  for  syntactic  side-effect 
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analysis  using  the  effect  system.  The  results  of  this  section  do  not  deal  with 
effect  masking. 

Definition.  For  all  0  and  0'  such  that  0  O',  let 

•  A (0,0')  denote  the  location (s)  allocated  in  the  reduction  step  O' 

•  Z(0,0')  denote  the  location(s)  read  in  the  reduction  step  0  =>  O' 

•  W(0,0')  denote  the  location(s)  written  in  the  reduction  step  0  ==>■  O' 

Claim.  (Effect  Soundness)  Reduction  of  a  well-formed  state  allocates, 
reads,  and  writes  only  locations  in  the  regions  specified  by  its  effect.  In  other 
words,  if  0  O'  and  0  !  e  where 

e  ~  (maxefl  (alloc  px)  (read  p/ j)  (write  pw)) 

then 

mn  q  pa 
S(M')  £  PR 

W(9,0')  C  pw 

Because  reduction  preserves  or  reduces  the  effect  of  a  state,  this  claim 
generalizes  immediately  to  0  =>*  O'. 

Effect  soundness  means  that  the  syntactic  effect  descriptions  of  the  ordi¬ 
nary  expressions  that  constitute  a  program  are  a  conservative  approximation 
of  their  actual  effects.  It  follows  that  this  syntactic  effect  information  can  be 
used  to  identify,  at  compile  time,  ordinary  expressions  that  can  be  memoized 
and  ordinary  expressions  that  can  be  evaluated  concurrently. 

Effect  Masking 

In  the  presence  of  effect  masking,  the  effect  soundness  property  reads  as 
follows: 

Proposition  (revised).  (Effect  Soundness)  Reduction  of  an  expression 
in  a  well-formed  state  allocates,  reads,  and  writes  only  locations  that  can  be 
reached  through  the  regions  specified  by  its  effect  and/or  through  regions 
that  are  accessible  only  within  the  expression. 
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unit, 19, 50 

Value,  63 

constants,  31 
expression,  11,  30 
Value  expression,  29—47 
Variable,  30,  31 
description,  13 
free,  31 
ordinary,  31 

Variable-length  Application,  72 
vector,  76 
vector->list,  77 
vector-fill!, 76 
vector-length, 76 
vector-ref,  76 
vector-set ! , 76 
vectorof ,  75 
vlanbda,  71 
vsubr,  67,  70 

with-input-from-f ile,  102 
with-output-to-f ile,  102 
write, 16 
write-bool, 103 
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write-float,  103 
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